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Prologo a la traduccion 

Este trabajo de traduccion ha sido realizado integramente por voluntaries. Le 
agradecemos que nos comunique cualquier error de traduccion o transcription en el 
texto. Tambien sera bienvenido si desea colaborar mas activamente en la traduccion. 
Ayudenos a hacer de esta traduccion un trabajo de calidad. 

Si desea saber mas sobre este proyecto, obtener el segundo volumen, colaborar 
enviando informes de fallos, traduciendo o revisando, etc. visite la pagina web 1 o 
nuestro grupo Google 2 . 

El trabajo de traduccion de este volumen practicamente ha terminado, pero es 
posible que todavia queden muchos errores debido a que la revision es trabajosa 
y contamos con pocos voluntaries. Le agradecemos su colaboracion para corregir 
posibles erratas o fallos de cualquier tipo. En todo caso, el libro esta completo y es 
perfectamente util en su estado actual. 

Este prologo no forma parte del libro original y ha sido incluido como resena y 
referencia de los trabajos de traduccion que se han llevado a cabo. Este capitulo no 
lo dare por terminado hasta que concluya el proceso de traduccion y revision de este 
volumen al menos. La traduccion del Volumen 2 ya esta en marcha. 


Licencia y normas de distribution 

El equipo de traduccion ha seguido al pie de la letra las directrices marcadas por 
Bruce Eckel, autor de Thinking in C++ (el libro original), para la realization de tra- 
ducciones y distribution de estas. Si utiliza o distribuye este texto debe cumplirlas y 
advertir de su existencia a los posibles lectores. El equipo de traduccion elude toda 
responsabilidad por la violation (por parte de terceros) de las citadas directrices 3 . Se 
incluyen a continuation respetando el idioma original para evitar eventuales inter- 
pretaciones incorrectas: 

In my contract with the publisher, I maintain all electronic publishing 
rights to the book, including translation into foreign languages. This means 
that the publisher still handles negotiations for translations that are prin¬ 
ted (and I have nothing directly to do with that) but I may grant transla¬ 
tion rights for electronic versions of the book. 

I have been granting such rights for «open-source» style translation pro¬ 
jects. (Note that I still maintain the copyright on my material.) That is: 

■ You must provide a web site or other medium whereby people may 

1 http: / /arco.esi.uclm.es/~david.villa/pensarC++.html 

2 http: / / groups. google .com / group / pensar-en-epp 

3 El texto original de estas directrices esta accesible en la pagina web del autor. 
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participate in the project (two easy possibilities are http: / /www.egroups.com 
or http://www.topica.com). 

■ You must maintain a downloadable version of the partially or fully 
translated version of the book. 

■ Someone must be responsible for the organization of the translation 
(I cannot be actively involved - I don't have the time). 

■ There should only be one language translation project for each book. 

We don't have the resources for a fork. 

■ As in an open-source project, there must be a way to pass responsi¬ 
bility to someone else if the first person becomes too busy. 

■ The book must be freely distributable. 

■ The book may be mirrored on other sites. 

■ Names of the translators should be included in the translated book. 


Tecnicismos 

Se han traducido la mayor parte de los terminos especificos tanto de orientation a 
objetos como de programacion en general. Para evitar confusiones o ambigiiedades 
a los lectores que manejen literatura en ingles hemos incluido entre parentesis el 
termino original la primera vez que aparece traducido. 

Para traducir tecnicismos especialmente complicados hemos utilizado como refe¬ 
renda la segunda edicion de El lenguaje de Programacion C++ (en castellano) asi como 
la Wikipedia. 

En contadas ocasiones se ha mantenido el termino original en ingles. En benefi- 
cio de la legibilidad, hemos preferido no hacer traducciones demasiado forzadas ni 
utilizar expresiones que pudieran resultar desconocidas en el argot o en los libros 
especializados disponibles en castellano. Nuestro proposito es tener un libro que 
pueda ser comprendido por hispano-hablantes. Es a todas luces imposible realizar 
una traduccion rigurosa acorde con las normas linguisticas de la RAE, puesto que, 
en algunos casos, el autor incluso utiliza palabras de su propia invention. 


Codigo fuente 

Por hacer 


Produccion 

Todo el proceso de traduccion, edicion, formato y tipografia ha sido realizado 
integramente con software libre. Todo el software utilizado esta disponible en la dis¬ 
tribution Debian GNU/Linux, que es la que se ha utilizado principalmente para la 
actualization y mantenimiento de los documentos obtenidos como resultado. 

El texto ha sido escrito en el lenguaje de marcado DocBook version 4.5 en su 
variante XML. Cada capitulo esta contenido en un fichero independiente y todos 
ellos se incluyen en un fichero «maestro» utilizando XInclude. 

Debido a que muchos procesadores de DocBook no soportan adecuadamente la 
caracteristica XInclude, se usa la herramienta xsltproc 4 para generar un unico fiche- 

4 http: / /xmlsoft.org/XSLT7xsltproc2.html 
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ro XML que contiene el texto de todo el libro, y es ese fichero resultante el que se 
procesa. 


Codigo fuente 

Tambien se utiliza XInclude para anadir en su lugar el contenido de los ficheros 
de codigo fuente escritos en C++. De ese modo, el texto de los listados que aparecen 
en el libro es identico a los ficheros C++ que distribuye el autor. De ese modo, la 
edition es mucha mas limpia y sobretodo se evitan posibles errores de transcription 
de los listados. 

Utilizando un pequeno programa escrito en lenguaje Python 5 , se substituyen los 
nombres etiquetados de los ficheros por la sentencia XInclude correspondiente: 

//: V1C02:Hello.cpp 


pasa a ser: 

<example> 

<title>C02/Hello.cpp</title> 

<programlisting language="C++"> 

<xi:include parse="text" href="./code_vl/C02/Hello.cpp"/> 
</programlisting> 

</example> 


Una ver realizada esta substitution, se utiliza de nuevo xsltproc para montar 
tanto el texto como los listados en un unico fichero XML. 


Convenciones tipograficas 

■ Palabras reservadas: struct 

■ Codigo fuente: printf ( "Hello world"); 

■ Nombres de ficheros: fichero . cpp 

■ Aplicacion o fichero binario: make 

■ Entrecomillado: «upcasting» 


Esquemas y diagramas 

Los dibujos y diagramas originales se han rehecho en formato . svg usando la 
herramienta inkscape 6 . A partir del fichero fuente . svg se generan versiones en 
formato . png para la version HTML y . pdf para la version PDF. 


Generacion de productos 

A partir del documento completo en formato DocBook se generan dos resultados 
distintos; 

3 ./utils/fix_includes.py 

6 http://inkscape.org/ 
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HTML en una sola pagina Una pagina web XHTML. Para ello se utiliza tambien la 
herramienta xsltproc aplicando hojas de estilo XSLT que pueden encontrarse 
en el repositorio de fuentes del proyecto. Estas plantillas son modificaciones 
de las del proyecto de documentation del programa «The Gimp», que tienen 
licencia GPL. 

Para el coloreado de los listados de codigo fuente se ha utilizado el programa 
highlight. Para ello, un pequeno programa Python marca los listados para su 
extraction, a continuation se colorean y por ultimo se vuelven a insertar en la 
pagina HTML. 

HTML (una pagina por section) Un conjunto de paginas XHTML. Automaticamen- 
te se generan enlaces para navegar por el documento y tablas de contenidos. 

PDF Un documento en formato PDF utilizando la aplicacion dblatex 7 . Ha sido ne- 
cesario crear una hoja de estilo especificamente para manipular el formato de 
pagina, titulos e indices. Para el resalte de sintaxis de los listados se ha utilizado 
el paquete LaTeX listings. 


El equipo 

Las siguientes personas han colaborado en mayor o menor medida en algun mo¬ 
menta desde el comienzo del proyecto de traduccion de Pensar en C++: 

■ David Villa Alises (coordinador) dvilla#gmx.net 

■ Miguel Angel Garcia miguelangel.garcia#gmail.com 

■ Javier Corrales Garcia jcg#damir.iem.csic.es 

■ Barbara Teruggi bwire.red#gmail.com 

■ Sebastian Gurin 

■ Gloria Barberan Gonzalez globargon#gmail.com 

■ Fernando Perfumo Velazquez nperfumo#telefonica.net 

■ Jose Maria Gomez josemaria.gomez#gmail.com 

■ David Martinez Moreno ender#debian.org 

■ Cristobal Tello ctg#tinet.org 

■ Jesus Lopez Mollo (pre-Lucas) 

■ Jose Maria Requena Lopez (pre-Lucas) 

■ Javier Fenoll Rejas (pre-Lucas) 
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Utilidades 


7 http:/ /dblatex.sourceforge.net/ 
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Prefacio 

Como cualquier lenguaje humano, C++ proporciona metodos pa¬ 
ra expresar conceptos. Si se utiliza de forma correcta, este medio de 
expresion sera significativamente mas sencillo y flexible que otras 
alternativas cuando los problemas aumentan en tamano y compleji- 
dad. 

No se puede ver C++ solo como un conjunto de caracteristicas, ya que algunas 
de esas caracteristicas no tienen sentido por separado. Solo se puede utilizar la suma 
de las partes si se esta pensando en el diseno, no solo en el codigo. Y para entender 
C++ de esta forma, se deben comprender los problemas existentes con C y con la 
programacion en general. Este libro trata los problemas de programacion, porque 
son problemas, y el enfoque que tiene C++ para solucionarlos. Ademas, el conjunto 
de caracteristicas que explico en cada capitulo se basara en la forma en que yo veo 
un tipo de problema en particular y como resolverlo con el lenguaje. De esta forma 
espero llevar al lector, poco a poco, de entender C al punto en el que C++ se convierta 
en su propia lengua. 

Durante todo el libro, mi actitud sera pensar que el lector desea construir en su 
cabeza un modelo que le permita comprender el lenguaje bajando hasta sus raices; 
si se tropieza con un rompecabezas, sera capaz de compararlo con su modelo mental 
y deducir la respuesta. Tratare de comunicarle las percepciones que han reorientado 
mi cerebro para «Pensar en C++». 


Material nuevo en la segunda edicion 

Este libro es una minuciosa reescritura de la primera edicion para reflejar todos 
los cambios que han aparecido en C++ tras la finalization del estandar que lo rige, 
y tambien para reflejar lo que he aprendido desde que escribi la primera edicion. 
He examinado y reescrito el texto completo, en ocasiones quitando viejos ejemplos, 
a veces cambiandolos, y tambien anadiendo muchos ejercicios nuevos. La reorga¬ 
nization y reordenacion del material tuvo lugar para reflejar la disponibilidad de 
mejores herramientas, asi como mi mejor comprension de como la gente aprende 
C++. He anadido un nuevo capitulo, como introduction al resto del libro, una in¬ 
troduction rapida a los conceptos de C y a las caracteristicas basicas de C++ para 
aquellos que no tienen experiencia en C. El CD-ROM incluido al final del libro en la 
edicion en papel contiene un seminario: una introduction aun mas ligera a los con¬ 
ceptos de C necesarios para comprender C++ (o Java). Chuck Allison lo escribio para 
mi empresa (MindView, Inc.), y se llama «Pensar en C: conceptos basicos de Java y 
C++». Presenta los aspectos de C que necesita conocer para poder cambiar a C++ o 
Java, abandonando los desagradables bits de bajo nivel con los que los programa- 
dores de C tratan a diario, pero que lenguajes como C++ y Java mantienen lejos (o 
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incluso eliminan, en el caso de Java). 

Asi que la respuesta corta a la pregunta «^Que es diferente en la segunda edi- 
cion?» seria que aquello que no es completamente nuevo se ha reescrito, a veces 
hasta el punto en el que no podria reconocer los ejemplos y el material original de la 
primera edicion. 


^Que contiene el volumen 2 de este libro? 

Con la conclusion del estandar de C++ tambien se anadieron algunas importantes 
bibliotecas nuevas, tales como string y los contenedores, y algoritmos de la Libreria 
Estandar C++, y tambien se ha anadido complejidad a las plantillas. Estos y otros 
temas mas avanzados se han relegado al volumen 2 de este libro, incluyendo asuntos 
como la herencia multiple, el manejo de excepciones, patrones de diseno, y material 
sobre la creation y depuration de sistemas estables. 


Como obtener el volumen 2 

Del mismo modo que el libro que lee en estos momentos, Pensar en C++, Volumen 
2 se puede descargar desde mi sitio web www.BruceEckel.com. Puede encontrar in¬ 
formation en el sitio web sobre la fecha prevista para la impresion del Volumen 2. 

El sitio web tambien contiene el codigo fuente de los listados para ambos libros, 
junto con actualizaciones e information sobre otros seminarios en CD-ROM que ofre- 
ce Mid View Inc., seminarios publicos y formation interna, consultas, soporte y asis- 
tentes paso a paso. 


Requisitos 

En la primera edicion de este libro, decidi suponer que otra persona ya le habia 
ensenado C y que el lector tenia, al menos, un nivel aceptable de lectura del mismo. 
Mi primera intention fue hablar de lo que me resulto dificil: el lenguaje C++. En 
esta edicion he anadido un capitulo como introduction rapida a C, acompanada del 
seminario en-CD Thinking in C, pero sigo asumiendo que el lector tiene algun tipo 
de experiencia en programacion. Ademas, del mismo modo que se aprenden muchas 
palabras nuevas intuitivamente, viendolas en el contexto de una novela, es posible 
aprender mucho sobre C por el contexto en el que se utiliza en el resto del libro. 


Aprender C++ 

Yo me adentre en C++ exactamente desde la misma position en la que espero que 
se encuentren muchos de los lectores de este libro: como un programador con una 
actitud muy sensata y con muchos vicios de programacion. Peor aun, mi experiencia 
era sobre porgramacion de sistemas empotrados a nivel hardware, en la que a ve¬ 
ces se considera a C como un lenguaje de alto nivel y excesivamente ineficiente para 
ahorrar bits. Descubri mas tarde que nunca habia sido un buen programador en C, 
camuflando asi mi ignorancia sobre estructuras, malloc () y free (), set jmp () 
y long jmp (), y otros conceptos sofisticados, y muriendome de verguenza cuando 
estos terminos entraban en una conversation, en lugar de investigar su utilidad. 

Cuando comence mi lucha por aprender C++, el unico libro decente era la auto- 
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proclamada Gina de expertos de Bjarne Stroustrup 8 as! que simplifique los conceptos 
basicos por ml mismo. Esto se acabo convirtiendo en mi primer libro de C++ 9 , que 
es esencialmente un reflejo de mi experiencia. Fue descrita como una guia de lectura 
para atraer a los programadores a C y C++ al mismo tiempo. Ambas ediciones 10 del 
libro consiguieron una respuesta entusiasta. 

Mas o menos al mismo tiempo que aparecia Using C++, comence a ensenar el 
lenguaje en seminarios y presentaciones. Ensenar C++ (y mas tarde, Java) se con- 
virtio en mi profesion; llevo viendo cabezas asintiendo, caras palidas, y expresiones 
de perplejidad en audiencias por todo el mundo desde 1989. Cuando comence a dar 
formation interna a grupos mas pequenos, descubri algo durante los ejercicios. In- 
cluso aquella gente que estaba sonriendo y asintiendo se encontraba equivocada en 
muchos aspectos. Creando y dirigiendo las pruebas de C++ y Java durante muchos 
anos en la Conferencia de Desarrollo de Software, descubri que tanto otros oradores 
como yo tendiamos a tocar demasiados temas, y todo demasiado rapido. Asi que, de 
vez en cuando, a pesar de la variedad del nivel de la audiencia e independientemen- 
te de la forma en que se presentara el material, terminaria perdiendo alguna parte de 
mi publico. Quiza sea pedir demasiado, pero como soy una de esas personas que se 
resisten a una conferencia tradicional (y para la mayoria de las personas, creo, esta 
resistencia esta causada por el aburrimiento), quise intentar mantener a cada uno a 
su velocidad. 

Durante un tiempo, estuve haciendo presentaciones en orden secuencial. De ese 
modo, termine por aprender experimentando e iterando (una tecnica que tambien 
funciona bien en el diseno de programas en C++). Al final, desarrolle un curso usan- 
do todo lo que habia aprendido de mi experiencia en la ensenanza. Asi, el aprendiza- 
je se realiza en pequenos pasos, faciles de digerir, y de cara a un seminario practico 
(la situation ideal para el aprendizaje) hay ejercicios al final de cada presentation. 
Puede encontrar mis seminarios publicos en www.BruceEckel.com, y tambien pue- 
de aprender de los seminarios que he pasado a CD-ROM. 

La primera edition de este libro se gesto a lo largo de dos anos, y el material de 
este libro se ha usado de muchas formas y en muchos seminarios diferentes. Las reac- 
ciones que he percibido de cada seminario me han ayudado a cambiar y reorientar el 
material hasta que he comprobado que funciona bien como un medio de ensenanza. 
Pero no es solo un manual para dar seminarios; he tratado de recopilar tanta infor¬ 
mation como he podido en estas paginas, intentando estructurarlas para atraer al 
lector hasta la siguiente materia. Mas que nada, el libro esta disenado para servir al 
lector solitario que lucha con un lenguaje de programacion nuevo. 


Objetivos 

Mis objetivos en este libro son: 

1. Presentar el material paso a paso, de manera que el lector pueda digerir cada 
concepto facilmente antes de continuar. 

2. Usar ejemplos tan simples y cortos como sea posible. Esto a veces me impide 
manejar problemas del mundo real, pero he descubierto que los principiantes 

8 Bjarne Stroustrup, The C++ Programming Language, Addison-Wesley, 1986 (first edition). 

9 Using C++, Osborne/McGraw-Hill 1989. 

10 Using C++ and C++ Inside & Out, Osborne/McGraw-Hill 1993. 
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normalmente quedan mas contentos cuando pueden comprender cada detalle 
de un ejemplo que siendo impresionados por el ambito del problema que so- 
luciona. Ademas, hay un limite en la cantidad de codigo que se puede asimilar 
en una clase. Por ello, a veces recibo criticas por usar ejemplos de jugiiete, pero 
tengo la buena voluntad de aceptarlas en favor de producir algo pedagogica- 
mente util. 

3. La cuidadosa presentacion secuencial de capacidades para que no se vea algo 
que no ha sido explicado. De acuerdo, esto no siempre es posible; en esos casos, 
se ofrece una breve descripcion introductoria. 

4. Indicarle lo que creo que es importante para que se comprenda el lenguaje, 
mas que todo lo que se. Creo que hay una "jerarquia de la importancia de la 
informacion", y hay algunos hechos que el 95 por ciento de los programadores 
nunca necesitara saber y que solo podrian confundirles y afianzar su percep¬ 
tion de la complejidad del lenguaje. Tomando un ejemplo de C, si memoriza 
la tabla de precedencia de los operadores (yo nunca lo hice), puede escribir 
codigo mas corto. Pero si lo piensa, esto confundira al lector/mantenedor de 
ese codigo. Asi que olvide la precedencia, y utilice parentesis cuando las cosas 
no esten claras. Esta misma actitud la utilizare con alguna otra informacion del 
lenguaje C++, que creo que es mas importante para escritores de compiladores 
que para programadores. 

5. Mantener cada section suficientemente enfocada como para que el tiempo de 
lectura -y el tiempo entre bloques de ejercicios- sea razonable. Eso mantiene 
las mentes de la audiencia mas activas e involucradas durante un seminario 
practico, y ademas le da al lector una mayor sensation de avance. 

6. Ofrecer a los lectores una base solida de manera que puedan comprender las 
cuestiones lo suficientemente bien como para pasar a otros cursos y libros mas 
dificiles (en concreto, el Volumen 2 de este libro). 

7. He tratado de no utilizar ninguna version de C++ de ningun proveedor en 
particular porque, para aprender el lenguaje, no creo que los detalles de una 
implementacion concreta sean tan importantes como el lenguaje mismo. La 
documentation sobre las especificaciones de implementacion propia de cada 
proveedor suele ser adecuada. 


Capitulos 

C++ es un lenguaje en el que se construyen caracteristicas nuevas y diferentes 
sobre una sintaxis existente (por esta razon, nos referiremos a el como un lengua¬ 
je de programacion orientado a objetos htbrido). Como mucha gente pasa por una 
curva de aprendizaje, hemos comenzado por adaptarnos a la forma en que los pro¬ 
gramadores pasan por las etapas de las cualidades del lenguaje C++. Como parece 
que la progresion natural es la de una mente entrenada de forma procedural, he de- 
cidido comprender y seguir el mismo camino y acelerar el proceso proponiendo y 
resolviendo las preguntas que se me ocurrieron cuando yo aprendia el lenguaje y 
tambien las que se les ocurrieron a la gente a la que lo ensenaba. 

El curso fue disenado con algo en mente: hacer mas eficiente el proceso de apren¬ 
der C++. La reaction de la audiencia me ayudo a comprender que partes eran difi¬ 
ciles y necesitaban una aclaracion extra. En las areas en las que me volvia ambicioso 
e incluia demasiadas cosas de una vez, me di cuenta -mediante la presentacion de 
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material- de que si incluyes demasiadas caracteristicas, tendras que explicarlas to- 
das, y es facil que la confusion de los estudiantes se agrave. Como resultado, he 
tenido muchos problemas para introducir las caracteristicas tan lentamente como ha 
sido posible; idealmente, solo un concepto importante a la vez por capitulo. 

Asi pues, el objetivo en cada capitulo es ensenar un concepto simple, o un peque- 
no grupo de conceptos asociados, en caso de que no haya mas conceptos adicionales. 
De esa forma puede digerir cada parte en el contexto de su conocimiento actual an¬ 
tes de continuar. Para llevarlo a cabo, deje algunas partes de C para mas adelante de 
lo que me hubiese gustado. La ventaja es que se evita la confusion al no ver todas 
las caracteristicas de C++ antes de que estas sean explicadas, asi su introduccion al 
lenguaje sera tranquila y reflejara la forma en que asimile las caracteristicas que dejo 
en sus manos. 

He aqui una breve description de los capitulos que contiene este libro: 

Capitulo 1: Introduccion a los objetos. Cuando los proyectos se vuelven dema- 
siado grandes y dificiles de mantener, nace la «crisis del softwares que es cuando 
los programadores dicen: «jNo podemos terminar los proyectos, y cuando podemos, 
son demasiado caros!». Eso provoco gran cantidad de reacciones, que se discuten en 
este capitulo mediante las ideas de Programacion Orientada a Objetos (POO) y como 
intenta esta resolver la crisis del software. El capitulo le lleva a traves de las caracte¬ 
risticas y conceptos basicos de la POO y tambien introduce los procesos de analisis 
y diseno. Ademas, aprendera acerca de los beneficios y problemas de adaptar el len¬ 
guaje, y obtendra sugerencias para adentrarse en el mundo de C++. 

Capitulo 2: Crear y usar objetos. Este capitulo explica el proceso de construir 
programas usando compiladores y librerias. Presenta el primer programa C++ del 
libro y muestra como se construyen y compilan los programas. Despues se presentan 
algunas de las librerias de objetos basicas disponibles en C++ Estandar. Para cuando 
acabe el capitulo, dominara lo que se refiere a escribir un programa C++ utilizando 
las librerias de objetos predefinidas. 

Capitulo 3: El C de C++. Este capitulo es una densa vista general de las caracte¬ 
risticas de C que se utilizan en C++, asi como gran numero de caracteristicas basicas 
que solo estan disponibles en C++. Ademas introduce la utilidad make, que es ha¬ 
bitual en el desarrollo software de todo el mundo y que se utiliza para construir 
todos los ejemplos de este libro (el codigo fuente de los listados de este libro, que 
esta disponible enwww.BruceEckel.com, contiene los makefiles correspondientes 
a cada capitulo). En el capitulo 3 supongo que el lector tiene unos conocimientos 
basicos solidos en algun lenguaje de programacion procedural como Pascal, C, o in- 
cluso algun tipo de Basic (basta con que haya escrito algo de codigo en ese lenguaje, 
especialmente funciones). Si encuentra este capitulo demasiado dificil, deberia mirar 
primero el seminario Pensar en C del CD que acompana este libro (tambien disponi¬ 
ble en www.BruceEckel.com). 

Capitulo 4: Abstraction de datos. La mayor parte de las caracteristicas de C++ 
giran entorno a la capacidad de crear nuevos tipos de datos. Esto no solo ofrece una 
mayor organization del codigo, tambien es la base preliminar para las capacidades 
de POO mas poderosas. Vera como esta idea es posible por el simple hecho de poner 
funciones dentro de las estructuras, los detalles de como hacerlo, y que tipo de codi¬ 
go se escribe. Tambien aprendera la mejor manera de organizar su codigo mediante 
archivos de cabecera y archivos de implementation. 

Capitulo 5: Ocultar la implementation. El programador puede decidir que algu- 
nos de los datos y funciones de su estructura no esten disponibles para el usuario del 
nuevo tipo haciendolas prwadas. Eso significa que se puede separar la implementa¬ 
tion principal de la interfaz que ve el programador cliente, y de este modo permitir 
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que la implementacion se pueda cambiar facilmente sin afectar al codigo del clien- 
te. La palabra clave class tambien se presenta como una manera mas elaborada de 
describir un tipo de datos nuevo, y se desmitifica el significado de la palabra «objeto» 
(es una variable elaborada). 

Capitulo 6: Inicializacion y limpieza. Uno de los errores mas comunes en C se 
debe a las variables no inicializadas. El constructor de C++ permite garantizar que las 
variables de su nuevo tipo de datos («objetos de su clase») siempre se inicializaran 
correctamente. Si sus objetos tambien requieren algun tipo de reciclado, usted puede 
garantizar que ese reciclado se realice siempre mediante el destructor C++. 

Capitulo 7: Sobrecarga de funciones y argumentos por defecto. C++ esta pensa- 
do para ayudar a construir proyectos grandes y complejos. Mientras lo hace, puede 
dar lugar a multiples librerias que utilicen el mismo nombre de funcion, y tambien 
puede decidir utilizar un mismo nombre con diferentes significados en la misma 
biblioteca. Con C++ es sencillo gracias a la «sobrecarga de funciones», lo que le per¬ 
mite reutilizar el mismo nombre de funcion siempre que la lista de argumentos sea 
diferente. Los argumentos por defecto le permiten llamar a la misma funcion de dife¬ 
rentes maneras proporcionando, automaticamente, valores por defecto para algunos 
de sus argumentos. 

Capitulo 8: Constantes. Este capitulo cubre las palabras reservadas const y v- 
olatile, que en C++ tienen un significado adicional, especialmente dentro de las 
clases. Aprendera lo que significa aplicar const a una definition de puntero. El ca¬ 
pitulo tambien muestra como varia el significado de const segun se utilice dentro 
o fuera de las clases y como crear constantes dentro de clases en tiempo de compila¬ 
tion. 

Capitulo 9: Funciones inline. Las macros del preprocesador eliminan la sobrecar¬ 
ga de llamada a funcion, pero el preprocesador tambien elimina la valiosa comproba- 
cion de tipos de C++. La funcion inline le ofrece todos los beneficios de una macro 
de preprocesador ademas de los beneficios de una verdadera llamada a funcion. Este 
capitulo explora minuciosamente la implementacion y uso de las funciones inline. 

Capitulo 10: Control de nombres. La election de nombres es una actividad fun¬ 
damental en la programacion y, cuando un proyecto se vuelve grande, el numero de 
nombres puede ser arrollador. C++ le permite un gran control de los nombres en fun¬ 
cion de su creation, visibilidad, lugar de almacenamiento y enlazado. Este capitulo 
muestra como se controlan los nombres en C++ utilizando dos tecnicas. Primero, la 
palabra reservada static se utiliza para controlar la visibilidad y enlazado, y se ex¬ 
plora su significado especial para clases. Una tecnica mucho mas util para controlar 
los nombres a nivel global es el namespace de C++, que le permite dividir el espacio 
de nombres global en distintas regiones. 

Capitulo 11: Las referencias y el constructor de copia. Los punteros de C++ tra- 
bajan como los punteros de C con el beneficio adicional de la comprobacion de tipos 
mas fuerte de C++. C++ tambien proporciona un metodo adicional para manejar 
direcciones: C++ imita la referenda de Algol y Pascal, que permite al compilador ma- 
nipular las direcciones, pero utilizando la notation ordinaria. Tambien encontrara el 
constructor-de-copia, que controla la manera en que los objetos se pasan por valor 
hacia o desde las funciones. Finalmente, se explica el puntero-a-miembro de C++. 

Capitulo 12: Sobrecarga de operadores. Esta caracteristica se llama algunas ve- 
ces «azucar sintactico»; permite dulcificar la sintaxis de uso de su tipo permitiendo 
operadores asi como llamadas a funciones. En este capitulo aprendera que la sobre¬ 
carga de operadores solo es un tipo de llamada a funcion diferente y aprendera como 
escribir sus propios operadores, manejando el -a veces confuso- uso de los argumen¬ 
tos, devolviendo tipos, y la decision de si implementar el operador como metodo o 
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funcion amiga. 

Capitulo 13: Creation dinamica de objetos. ^Cuantos aviones necesitara manejar 
un sistema de trafico aereo? ^Cuantas figuras requerira un sistema CAD? En el pro- 
blema de la programacion generica, no se puede saber la cantidad, tiempo de vida 
o el tipo de los objetos que necesitara el programa una vez lanzado. En este capi¬ 
tulo aprendera como new y delete solventan de modo elegante este problema en 
C++ creando objetos en el monton. Tambien vera como new y delete se pueden 
sobrecargar de varias maneras, de forma que puedan controlar como se asigna y se 
recupera el espacio de almacenamiento. 

Capitulo 14: Herencia y composicion. La abstraction de datos le permite crear ti- 
pos nuevos de la nada, pero con composicion y herencia, se puede crear tipos nuevos 
a partir de los ya existentes. Con la composicion, se puede ensamblar un tipo nuevo 
utilizando otros tipos como piezas y, con la herencia, puede crear una version mas 
especifica de un tipo existente. En este capitulo aprendera la sintaxis, como redefi- 
nir funciones y la importancia de la construction y destruction para la herencia y la 
composicion. 

Capitulo 15: Polimorfismo y funciones virtuales. Por su cuenta, podria llevarle 
nueve meses descubrir y comprender esta piedra angular de la POO. A traves de 
ejercicios pequenos y simples, vera como crear una familia de tipos con herencia y 
manipular objetos de esa familia mediante su clase base comun. La palabra reservada 
virtual le permite tratar todos los objetos de su familia de forma generica, lo que 
significa que el grueso del codigo no depende de information de tipo especifica. Esto 
hace extensibles sus programas, de manera que construir programas y mantener el 
codigo sea mas sencillo y mas barato. 

Capitulo 16: Introduction a las plantillas. La herencia y la composicion permiten 
reutilizar el codigo objeto, pero eso no resuelve todas las necesidades de reutiliza- 
cion. Las plantillas permiten reutilizar el codigo fuente proporcionando al compila- 
dor un medio para sustituir el nombre de tipo en el cuerpo de una clase o funcion. 
Esto da soporte al uso de bibliotecas de clase contenedor , que son herramientas im- 
portantes para el desarrollo rapido y robusto de programas orientados a objetos (la 
Biblioteca Estandar de C++ incluye una biblioteca significativa de clases contene¬ 
dor). Este capitulo ofrece una profunda base en este tema esencial. 

Temas adicionales (y materias mas avanzadas) estan disponibles en el Volumen 
2 del libro, que se puede descargar del sitio web www.BruceEckel.com. 


Ejercicios 

He descubierto que los ejercicios son excepcionalmente utiles durante un semina- 
rio para completar la comprension de los estudiantes, asi que encontrara algunos al 
final de cada capitulo. El numero de ejercicios ha aumentado enormemente respecto 
a la primera edition. 

Muchos de los ejercicios son suficientemente sencillos como para que puedan ter- 
minarse en una cantidad de tiempo razonable en una clase o apartado de laboratorio 
mientras el profesor observa, asegurandose de que todos los estudiantes asimilan el 
material. Algunos ejercicios son un poco mas complejos para mantener entretenidos 
a los estudiantes avanzados. El grueso de los ejercicios estan orientados para ser re- 
sueltos en poco tiempo y se intenta solo probar y pulir sus conocimientos mas que 
presentar retos importantes (seguramente ya los encontrara por su cuenta -o mejor 
dicho-, ellos lo encontraran a usted). 
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Soluciones a los ejercicios 

Las soluciones a los ejercicios seleccionados pueden encontrarse en el documento 
electronico El Solucionario de Pensar en C++, disponible por una pequena cantidad en 
www.BruceEckel.com. 


Codigo fuente 

El codigo fuente de los listados de este libro esta registrado como freeware, distri- 
buido mediante el sitio Web www.BruceEckel.com. El copyright le impide publicar 
el codigo en un medio impreso sin permiso, pero se le otorga el derecho de usarlo de 
muchas otras maneras (ver mas abajo). 

El codigo esta disponible en un fichero comprimido, destinado a extraerse des- 
de cualquier plataforma que tenga una utilidad zip (puede buscar en Internet para 
encontrar una version para su platarforma si aun no tiene una instalada). En el di- 
rectorio inicial donde desempaquete el codigo encontrara la siguiente nota sobre 
derechos de copia: 

Copyright (c) 2000, Bruce Eckel 

Source code file from the book "Thinking in C++" 

All rights reserved EXCEPT as allowed by the 
following statements: You can freely use this file 
for your own work (personal or commercial), 
including modifications and distribution in 
executable form only. Permission is granted to use 
this file in classroom situations, including its 
use in presentation materials, as long as the book 
"Thinking in C++" is cited as the source. 

Except in classroom situations, you cannot copy 
and distribute this code; instead, the sole 
distribution point is http://www.BruceEckel.com 
(and official mirror sites) where it is 
available for free. You cannot remove this 
copyright and notice. You cannot distribute 
modified versions of the source code in this 
package. You cannot use this file in printed 
media without the express permission of the 
author. Bruce Eckel makes no representation about 
the suitability of this software for any purpose. 

It is provided "as is" without express or implied 
warranty of any kind, including any implied 
warranty of merchantability, fitness for a 
particular purpose, or non-infringement. The entire 
risk as to the quality and performance of the 
software is with you. Bruce Eckel and the 
publisher shall not be liable for any damages 
suffered by you or any third party as a result of 
using or distributing this software. In no event 
will Bruce Eckel or the publisher be liable for 
any lost revenue, profit, or data, or for direct, 
indirect, special, consequential, incidental, or 
punitive damages, however caused and regardless of 
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the theory of liability, arising out of the use of 
or inability to use software, even if Bruce Eckel 
and the publisher have been advised of the 
possibility of such damages. Should the software 
prove defective, you assume the cost of all 
necessary servicing, repair, or correction. If you 
think you've found an error, please submit the 
correction using the form you will find at 
www.BruceEckel.com. (Please use the same 
form for non-code errors found in the book.) 


Se puede usar el codigo en proyectos y clases siempre y cuando se mantenga la 
nota de copyright. 


Estandares del lenguaje 

Durante todo el libro, cuando se haga referenda al estandar de C ISO, general- 
mente se dira «C». Solo si se necesita distinguir entre C estandar y otros mas viejos, 
versiones previas al estandar de C, se hara una distincion. 

Cuando se escribio este libro, el Comite de Estandares de C++ ya habia terminado 
de trabajar en el lenguaje. Por eso, se usara el termino C++ Estandar para referirse al 
lenguaje estandarizado. Si se hace referencia simplemente a C++, deberia asumir que 
se quiere decir «C++ Estandar». 

Hay alguna confusion sobre el nombre real del Comite de Estandares de C++ y el 
nombre del estandar mismo. Steve damage, el presidente del comite, clarified esto: 

Hay dos comites de estandarizacion de C++: El comite NCITS (antigua- 
mente X3) J16 y el comite ISO JTC1/SC22/WG14. ANSI alquila NCITS 
para crear comites tecnicos para desarrollar estandares nacionales ameri- 
canos. 

J16 fue alquilado en 1989 para crear un estandar americano para C++. 

Por el ano 1991 se alquilo WG14 para crear un estandar internacional. 

El proyecto J16 se convirtio en un proyecto «Tipo I» (Internacional) y se 
subordino al esfuerzo de estandarizacion de ISO. 

Los dos comites se encontraban al mismo tiempo en el mismo sitio, y 
el voto de J16 constituye el voto americano con WG14. WG14 delega el 
trabajo tecnico a J16. WG14 vota por el trabajo tecnico de J16. 

El estandar de C++ fue creado originalmente como un estandar ISO. AN¬ 
SI voto mas tarde (como recomendaba J16) para adoptar el estandar de 
C++ ISO como el estandar americano para C++. 

Por eso, «ISO» es la forma correcta de referirse al Estandar C++. 


Soporte del lenguaje 

Puede que su compilador no disponga de todas las caracteristicas discutidas en 
este libro, especialmente si no tiene la version mas recente del compilador. Imple- 



© 


"Volumenl" — 2012/1/12 — 13:52 — page XXXIV — #34 


© 


© 


© 


Prefacio 


mentar un lenguaje como C++ es una tarea herculea, y puede esperar que las carac- 
teristicas apareceran poco a poco en lugar de todas a la vez. Pero si prueba uno de 
los ejemplos del libro y obtiene un monton de errores del compilador, no es nece- 
sariamente un error en el codigo o en el compilador; simplemente puede no estar 
implementado aun en su compilador particular. 


El CD-ROM del libro 

El contenido principal del CD-ROM empaquetado al final de este libro es un 
«seminario en CD-ROM» titulado Pensar en C: Fundamentos para Jai’a y C++ obra de 
Chuck Allison (publicado por MindView, Inc., y tambien disponible en www.BruceEckel.com). 
Contiene muchas horas de grabaciones y transparencias, que pueden mostrarse en 
la mayoria de las computadoras que dispongan de lector de CD-ROM y sistema de 
sonido. 

El objetivo de Pensar en C es llevarle cuidadosamente a traves de los fundamentos 
del lenguaje C. Se centra en el conocimiento que necesita para poder pasarse a C++ o 
Java en lugar de intentar hacerle un experto en todos los recovecos de C (una de las 
razones de utilizar un lenguaje de alto nivel como C++ o Java es, precisamente, que 
se pueden evitar muchos de esos recovecos). Tambien contiene ejercicios y soluciones 
guiadas. Tengalo en cuenta porque el Capitulo 3 de este libro va mas alia del CD de 
Pensar en C, el CD no es una alternativa a este capitulo, sino que deberia utilizarse 
como preparation para este libro. 

Por favor, tenga en cuenta que el CD-ROM esta basado en navegador, por lo que 
deberia tener un navegador Web instalado en su maquina antes de utilizarlo. 


CD-ROMs, seminarios, y consultoria 

Hay seminarios en CD-ROM planeados para cubrir el Volumen 1 y el Volumen 
2 de este libro. Comprenden muchas horas de grabaciones mias que acompanan las 
transparencias que cubren el material seleccionado de cada capitulo del libro. Se 
pueden ver en la mayoria de las computadoras que disponen de lector de CDROM 
y sistema de sonido. Estos CDs pueden comprarse en www.BruceEckel.com, donde 
encontrara mas information y lecturas de ejemplo. 

Mi compania, MindView, Inc., proporciona seminarios publicos de preparation 
practica basados en el material de este libro y tambien en temas avanzados. El mate¬ 
rial seleccionado de cada capitulo representa una lection, que se contimia con un pe- 
riodo de ejercicios monitorizados para que cada estudiante reciba atencion personal. 
Tambien proporcionamos preparation «in situ», consultoria, tutorizacion, diseno y 
asistentes de codigo. Puede encontrar la information y los formularios para los pro- 
ximos seminarios, asi como otra information de contacto, en www.BruceEckel.com. 

A veces me encuentro disponible para consultas de diseno, evaluation de pro- 
cesos y asistencia. Cuando comence a escribir sobre computadoras, mi motivation 
principal fue incrementar mis actividades de consultoria, porque encontraba que la 
consultoria era competitiva, educational, y una de mis experiencias profesionales 
mas valiosas. Asi que hare todo lo que pueda para incluirle a usted en mi agenda, 
o para ofrecerle uno de mis socios (que son gente que conozco bien y con la que he 
tratado, y a menudo co-desarrollan e imparten seminarios conmigo). 
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Errores 

No importa cuantos trucos emplee un escritor para detectar los errores, algunos 
siempre se escapan y saltan del papel al lector atento. Si encuentra algo que crea 
que es un error, por favor, utilice el formulario de correcciones que encontrara en 
www.BruceEckel.com. Se agradece su ayuda. 


Sobre la portada 

La primera edicion de este libro tenia mi cara en la portada, pero para la segunda 
edicion yo querla desde el principio una portada que se pareciera mas una obra de 
arte, como la portada de Pensar en Java. Por alguna razon, C++ parece sugerirme Art 
Deco con sus curvas simples y pinceladas cromadas. Tenia en mente algo como esos 
carteles de barcos y aviones con cuerpos largos. 

Mi amigo Daniel Will-Harris, (www.Will-Harris.com) a quien conod en las clases 
del coro del instituto, iba a llegar a ser un disenador y escritor de talla mundial. 
El ha hecho practicamente todos mis disenos, inclulda la portada para la primera 
edicion de este libro. Durante el proceso de diseno de la portada, Daniel, insatisfecho 
con el progreso que realizabamos, siempre preguntaba: «,;Que relation hay entre las 
personas y las computadoras?». Estabamos atascados. 

Como capricho, sin nada en mente, me pidio que pusiera mi cara en el escaner. 
Daniel tenia uno de sus programas graficos (Corel Xara, su favorito) que «autotra- 
zo» mi cara escaneada. El lo describe de la siguente manera: «E1 autotrazado es la 
forma en la que la computadora transforma un dibujo en los tipos de llneas y curvas 
que realmente le gustan». Entonces jugo con ello hasta que obtuvo algo que parecla 
un mapa topografico de mi cara, una imagen que podrla ser la manera en que la 
computadora ve a la gente. 

Cog! esta imagen y la fotocopie en papel de acuarela (algunas copiadoras pueden 
manejar papeles gruesos), y entonces comenzo a realizar montones de experimentos 
anadiendo acuarela a la imagen. Seleccionamos las que nos gustaban mas, entonces 
Daniel las volvio a escanear y las organizo en la portada, anadiendo el texto y otros 
elementos de diseno. El proceso total requirio varios meses, mayormente a causa del 
tiempo que me tomo hacer las acuarelas. Pero me he divertido especialmente porque 
consegul participar en el arte de la portada, y porque me dio un incentivo para hacer 
mas acuarelas (lo que dicen sobre la practica realmente es cierto). 


Diseno del libro y produccion 

El diseno del interior del libro fue creado por Daniel Will-Harris, que solia ju- 
gar con letras (FIXME:rub-on) en el instituto mientras esperaba la invention de las 
computadoras y la publication de escritorio. De todos modos, yo mismo produje las 
paginas para impresion ( camera-ready ), por lo que los errores tipograficos son mios. 
Se utilizo Microsoft® Word para Windows Versiones 8 y 9 para escribir el libro y 
crear la version para impresion, incluyendo la generation de la tabla de conteni- 
dos y el indice (cree un servidor automatizado COM en Python, invocado desde las 
macros VBA de Word, para ayudarme en el marcado de los indices). Python (vea 
www.python.com) se utilizo para crear algunas de las herramientas para compro- 
bar el codigo, y lo habria utilizado como herramienta de extraction de codigo si lo 
hubiese descubierto antes. 

Cree los diagramas utilizando Visio®. Gracias a Visio Corporation por crear una 
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herramienta tan util. 

El tipo de letra del cuerpo es Georgia y los titulos utilizan Verdana. La version 
definitiva se creo con Adobe® Acrobat 4 y el fichero generado se llevo directamente a 
la imprenta - muchas gracias a Adobe por crear una herramienta que permite enviar 
documentos listos para impresion por correo electronico, asi como permitir que se 
realicen multiples revisiones en un unico dia en lugar de recaer sobre mi impresora 
laser y servicios rapidos 24 horas (probamos el proceso Acrobat por primera vez con 
Pensar en Java, y fui capaz de subir la version final de ese libro a la imprenta de U.S. 
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1: Introduction a los Objetos 

El origen de la revolution informatica ocurrio dentro de una ma- 
quina. Por tan to, el origen de nuestros lenguajes de programacion 
tiende a parecerse a esa maquina. 


Pero los ordenadores no son tanto maquinas como herramientas de amplificacion 
de la mente («bicicletas para la mente», como le gusta decir a Steve Jobs) y un me¬ 
dio de expresion diferente. Como resultado, las herramientas empiezan a parecerse 
menos a las maquinas y mas a partes de nuestra mente, y tambien a otros medios de 
expresion como la escritura, la pintura, la escultura, la animacion y la cinematogra- 
fia. La programacion orientada a objetos es parte de este movimiento hacia un uso 
del ordenador como medio de expresion. 

Este capitulo le servira de introduccion a los conceptos basicos de la programa¬ 
cion orientada a objetos (POO), incluyendo un resumen de los metodos de desarrollo 
de la POO. Este capitulo, y este libro, presuponen que el lector ya tiene experien- 
cia con un lenguaje de programacion procedural, aunque no tiene porque ser C. Si 
cree que necesita mas preparacion en programacion y en la sintaxis de C antes de 
abordar este libro, deberia leer el CD-ROM de entrenamiento Thinking in C: Foun¬ 
dations for C++ and java , que acompana a este libro, y esta disponible tambien en 
www.BruceEckel.com. 

Este capitulo contiene material basico y suplementario. Mucha gente no se siente 
comoda adentrandose en la programacion orientada a objetos sin tener antes una 
vision global. Por eso, aqui se introducen muchos conceptos que intentan darle una 
vision solida de la POO. Sin embargo, muchas personas no captan los conceptos glo- 
bales hasta que no han visto primero parte de la mecanica; puede que se atasquen o 
se pierdan si no hay ningun trozo de codigo al que ponerle las manos encima. Si us- 
ted pertenece a este ultimo grupo, y esta ansioso por llegar a las especificaciones del 
lenguaje, sientase libre de saltar este capitulo; eso no le impedira escribir programas 
o aprender el lenguaje. Sin embargo, quiza quiera volver a este capitulo para com- 
pletar sus conocimientos y poder comprender porque son importantes los objetos y 
como disenar con ellos. 


1.1. El progreso de abstraccion 

Todos los lenguajes de programacion proporcionan abstracciones. Se puede afir- 
mar que la complejidad de los problemas que se pueden resolver esta directamente 
relacionada con el tipo y calidad de la abstraccion. Por «tipo» me refiero a «^Que 
es lo que esta abstrayendo?». El lenguaje ensamblador es una pequena abstraccion 
de la maquina subyacente. Muchos lenguajes llamados «imperativos» que siguie- 
ron (como Fortran, BASIC y C) eran abstracciones del lenguaje ensamblador. Estos 
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lenguajes suponen grandes mejoras con respecto al lenguaje ensamblador, pero su 
abstraccion primaria todavia requiere pensar en terminos de la estructura del orde- 
nador, en lugar de la estructura del problema que intenta resolver. El programador 
debe establecer la asociacion entre el modelo de la maquina (en el «espacio de solu- 
ciones», que es el lugar donde esta modelando ese problema, como un ordenador) y 
el modelo del problema que se esta resolviendo (en el «espacio de problemas», que 
es el lugar donde existe el problema). El esfuerzo requerido para realizar esta corres- 
pondencia, y el hecho de que sea extrinseco al lenguaje de programacion, produce 
programas diddles de escribir y caros de mantener y, como efecto secundario, creo 
toda la industria de «metodos de programacion». 

La alternativa a modelar la maquina es modelar el problema que esta intentando 
resolver. Los primeros lenguajes como LISP y APL eligieron concepciones del mun- 
do particulares («Todos los problemas son listas en ultima instancia», o «Todos los 
problemas son algoritmicos»). PROLOG reduce todos los problemas a cadenas de 
decisiones. Se han creado lenguajes para programacion basados en restricciones y 
para programar manipulando exclusivamente simbolos graficos (lo ultimo demos- 
tro ser demasiado restrictivo). Cada uno de estos metodos es una buena solucion 
para el tipo particular de problema para el que fueron disenados, pero cuando uno 
sale de ese dominio se hacen diddles de usar. 

El metodo orientado a objetos va un paso mas alia, proporcionando herramien- 
tas para que el programador represente los elementos en el espacio del problema. 
Esta representation es lo suficientemente general como para que el programador no 
este limitado a un tipo particular de problema. Nos referimos a los elementos en el 
espacio del problema, y a sus representaciones en el espacio de la solucion, como 
«objetos» (por supuesto, necesitara otros objetos que no tengan analogias en el es¬ 
pacio del problema). La idea es que permita al programa adaptarse al lenguaje del 
problema anadiendo nuevos tipos de objetos de modo que cuando lea el codigo que 
describe la solucion, este leyendo palabras que ademas expresan el problema. Es un 
lenguaje de abstraccion mas flexible y potente que los que haya usado antes. De esta 
manera, la POO permite describir el problema en terminos del problema, en lugar 
de usar terminos de la computadora en la que se ejecutara la solucion. Sin embargo, 
todavia existe una conexion con la computadora. Cada objeto se parece un poco a 
una pequena computadora; tiene un estado y operaciones que se le puede pedir que 
haga. Sin embargo, no parece una mala analogia a los objetos en el mundo real; todos 
ellos tienen caracteristicas y comportamientos. 

Algunos disenadores de lenguajes han decidido que la programacion orientada 
a objetos en si misma no es adecuada para resolver facilmente todos los problemas 
de programacion, y abogan por una combination de varias aproximaciones en len¬ 
guajes de programacion multiparadigma . 1 

Alan Kay resumio las cinco caracteristicas basicas de Smalltalk, el primer lengua¬ 
je orientado a objetos con exito y uno de los lenguajes en los que esta basado C++. 
Esas caracteristicas representan una aproximacion a la programacion orientada a ob¬ 
jetos: 

1. Todo es un objeto. Piense en un objeto como una variable elaborada; almace- 
na datos, pero puede «hacer peticiones» a este objeto, solicitando que realice 
operaciones en si mismo. En teoria, puede coger cualquier componente con¬ 
ceptual del problema que esta intentando resolver (perros, edificios, servicios, 
etc.) y representarlos como un objeto en su programa. 

1 Ver Multiparadigm Programming in Leda de Timothy Budd (Addison-Wesley 1995). 
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2. Un programa es un grupo de objetos enviando mensajes a otros para decirles 
que hacer. Para hacer una peticion a un objeto, «envia un mensaje» a ese ob¬ 
jeto. Mas concretamente, puede pensar en un mensaje como una peticion de 
invocation a una funcion que pertenece a un objeto particular. 

3. Cada objeto tiene su propia memoria constituida por otros objetos. Visto de 
otra manera, puede crear un nuevo tipo de objeto haciendo un paquete que 
contenga objetos existentes. Por consiguiente, puede hacer cosas complejas en 
un programa ocultando la complejidad de los objetos. 

4. Cada objeto tiene un tipo. Usando el argot, cada objeto es una instancia de una 
clase, en el que «clase» es sinonimo de «tipo». La caracteristica mas importante 
que lo distingue de una clase es «^Que mensajes puede enviarle?» 

5. Todos los objetos de un tipo particular pueden recibir los mismos mensajes. En 
realidad es una frase con doble sentido, como vera mas tarde. Como un objeto 
de tipo circulo es tambien un objeto de tipo f igura, esta garantizado que un 
circulo aceptara los mensajes de figura. Esto significa que puede escribir codigo 
que habla con objetos figura y automaticamente funcionara con cualquier 
otro objeto que coincida con la description de figura. Esta sustituibilidad es 
uno de los conceptos mas poderosos en la POO. 


1.2. Cada objeto tiene una interfaz 

Aristoteles fue probablemente el primero en hacer un estudio minucioso del con- 
cepto de tipo ; el hablo de «la clase de peces y la clase de pajaros». La idea de que 
todos los objetos, aun siendo unicos, tambien son parte de una clase de objetos que 
tienen caracteristicas y comportamientos comunes se utilizo directamente en el pri¬ 
mer lenguaje orientado a objetos, Simula-67, con su palabra reservada class que 
introduce un nuevo tipo en un programa. 

Simula, como su nombre indica, fue creado para desarrollar simulaciones como el 
clasico «problema del cajero» 2 . Tiene un grupo de cajeros, clientes, cuentas, transac- 
ciones, y unidades de moneda - un monton de «objetos». Los objetos identicos, ex- 
ceptuando su estado durante la ejecucion del programa, se agrupan en «clases de 
objetos» y de ahi viene la palabra reservada class. Crear tipos de datos abstrac- 
tos (clases) es un concepto fundamental en la programacion orientada a objetos. Los 
tipos de datos abstractos trabajan casi exactamente como tipos predefinidos: puede 
crear variables de un tipo (llamadas objetos o instancias en el argot de la programacion 
orientada a objetos) y manipular estas variables (llamado emno de mensajes o peticio- 
nes ; envia un mensaje y el objeto decide que hacer con el). Los miembros (elementos) 
de cada clase tienen algo en comun: cada cuenta tiene un balance, cada cajero puede 
aceptar un deposito, etc. A1 mismo tiempo, cada miembro tiene su propio estado, 
cada cuenta tiene un balance diferente, cada cajero tiene un nombre. De este mo- 
do, cada cajero, cliente, cuenta, transaction, etc., se puede representar con una unica 
entidad en el programa de computador. Esta entidad es un objeto, y cada objeto per¬ 
tenece a una clase particular que define sus caracteristicas y comportamientos. 

Por eso, lo que hace realmente un programa orientado a objetos es crear nue- 
vos tipos de datos, practicamente todos los lenguajes de programacion orientados a 
objetos usan la palabra reservada class. Cuando vea la palabra «type», piense en 


2 Puede encontrar una implementation interesante de este problema en el Volumen 2 de este libro, 
disponible en www.BruceEckel.com 
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«class» y viceversa 3 . 

Dado que una clase describe un conjunto de objetos que tienen identicas caracte- 
risticas (elementos de datos) y comportamientos (funcionalidad), una clase es real- 
mente un tipo de datos porque un numero de punto flotante, por ejemplo, tambien 
tiene un conjunto de caracteristicas y comportamientos. La diferencia esta en que el 
programador define una clase para resolver un problema en lugar de estar obligado 
a usar un tipo de dato existente disenado para representar una unidad de almace- 
namiento en una maquina. Amplia el lenguaje de programacion anadiendo nuevos 
tipos de datos especificos segun sus necesidades. El sistema de programacion acoge 
las nuevas clases y les presta toda la atencion y comprobacion de tipo que da a los 
tipos predefinidos. 

El enfoque orientado a objetos no esta limitado a la construction de simulaciones. 
Este o no de acuerdo con que cualquier problema es una simulation del sistema que 
esta disenando, el uso de tecnicas POO puede reducir facilmente un amplio conjunto 
de problemas a una solution simple. 

Una vez establecida una clase, puede hacer tantos objetos de esta clase como 
quiera, y manipularlos como si fueran elementos que existen en el problema que esta 
intentando resolver. De hecho, uno de los desafios de la programacion orientada a 
objetos es crear una correspondencia univoca entre los elementos en el espacio del 
problema y objetos en el espacio de la solution. 

Pero, ^como se consigue que un objeto haga algo util por usted? Debe haber 
una forma de hacer una petition al objeto para que haga algo, como completar una 
transaction, dibujar algo en la pantalla o activar un interruptor. Y cada objeto pue¬ 
de satisfacer solo ciertas peticiones. Las peticiones que puede hacer un objeto estan 
definidas por su intefaz, y es el tipo lo que determina la interfaz. Un ejemplo simple 
puede ser una representation de una bombilla: 


Nombre del Tipo 


Interfaz 



encender( ) 
apagar( ) 
intensificar( ) 
atenuar( ) 



Figura 1.1: Clase Luz 


Luz luzl; 

luz1.encender(); 

La interfaz establece que peticiones se pueden hacer a un objeto particular. Sin 
embargo, se debe codificar en algun sitio para satisfacer esta petition. Esta, junto con 
los datos ocultos, constituyen la implementation. Desde el punto de vista de la progra¬ 
macion procedural, no es complicado. Un tipo tiene una funcion asociada para cada 
posible petition, y cuando se hace una petition particular a un objeto, se llama a esa 

3 Hay quien hace una distincion, afirmando que type determina la interfaz mientras class es una 
implementation particular de esta interfaz. 
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funcion. Este proceso normalmente se resume diciendo que ha «enviado un mensa- 
je» (ha hecho una peticion) a un objeto, y el objeto sabe que hacer con este mensaje 
(ejecuta codigo). 

Aqui, el nombre del tipo/clase es Luz, el nombre de este objeto particular de L- 
uz es luzl, y las peticiones que se le pueden hacer a un objeto Luz son encender, 
apagar, intensificar o atenuar. Puede crear un objeto Luz declarando un nombre (1- 
uzl) para ese objeto. Para enviar un mensaje al objeto, escriba el nombre del objeto 
y conectelo al mensaje de peticion con un punto. Desde el punto de vista del usuario 
de una clase predefinida, eso es practicamente todo lo que necesita para programar 
con objetos. 

El diagrama mostrado arriba sigue el formato del Lenguaje Unificado de Mode- 
lado (UML). Cada clase se representa con una caja, con el nombre del tipo en la parte 
de arriba, los atributos que necesite describir en la parte central de la caja, y los meto- 
dos (las funciones que pertenecen a este objeto, que reciben cualquier mensaje que se 
envie al objeto) en la parte inferior de la caja. A menudo, en los diagramas de diseno 
UML solo se muestra el nombre de la clase y el nombre de los metodos publicos, 
y por eso la parte central no se muestra. Si solo esta interesado en el nombre de la 
clase, tampoco es necesario mostrar la parte inferior. 


1.3. La implementacion oculta 

Es util distinguir entre los creadores de clases (aquellos que crean nuevos tipos de 
datos) y los programadores clientes 4 (los consumidores de clases que usan los tipos de 
datos en sus aplicaciones). El objetivo del programador cliente es acumular una caja 
de herramientas llena de clases que poder usar para un desarrollo rapido de aplica¬ 
ciones. El objetivo del creador de clases es construir una clase que exponga solo lo 
necesario para el programador cliente y mantenga todo lo demas oculto. ^Por que? 
Porque si esta oculto, el programador cliente no puede usarlo, lo cual significa que 
el creador de clases puede cambiar la parte oculta sin preocuparse de las consecuen- 
cias sobre lo demas. La parte oculta suele representar las interioridades delicadas de 
un objeto que podria facilmente corromperse por un programador cliente descuida- 
do o desinformado, asi que ocultando la implementacion se reducen los errores de 
programacion. No se debe abusar del concepto de implementacion oculta. 

En cualquier relacion es importante poner limites que sean respetados por todas 
las partes involucradas. Cuando se crea una libreria, se establece una relacion con el 
programador cliente, quien tambien es programador, porque puede estar utilizando 
la libreria para crear a su vez una libreria mayor. 

Si todos los miembros de una clase estan disponibles para cualquiera, entonces 
el programador cliente puede hacer cualquier cosa con la clase y no hay forma de 
imponer las reglas. Incluso si quisiera que el programador cliente no manipulase di- 
rectamente algunos de los miembros de su clase, sin control de acceso no hay forma 
de impedirlo. Nadie esta a salvo. 

Por eso la principal razon del control de acceso es impedir que el cliente toque 
las partes que no deberia (partes que son necesarias para los mecanismos infernos 
de los tipos de datos), pero no la parte de la interfaz que los usuarios necesitan para 
resolver sus problemas particulares. En realidad, esto es un servicio para los usuarios 
porque pueden ver facilmente lo que es importante para ellos y que pueden ignorar. 

La segunda razon para el control de acceso es permitir al disenador de la libre- 

4 Agradezco este termino a mi amigo Scott Meyers. 
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ria cambiar la implementacion interna de la clase sin preocuparse de como afectara 
a los programadores clientes. Por ejemplo, podria implementar una clase particular 
de una manera sencilla para un desarrollo facil, y mas tarde descubrir que necesita 
reescribirla para hacerla mas rapida. Si la interfaz y la implementacion estan cla- 
ramente separadas y protegidas, puede lograrlo facilmente y solo requiere que el 
usuario vuelva a enlazar la aplicacion. 

C++ utiliza tres palabras reservadas explicitas para poner limites en una clase: 
public, private, y protected. Su uso y significado son bastante sencillos. Estos 
especificadores de acceso determinan quien puede usar las definiciones que siguen. pu¬ 
blic significa que las definiciones posteriores estan disponibles para cualquiera. La 
palabra reservada private, por otro lado, significa que nadie puede acceder a estas 
definiciones excepto el creador del tipo, es decir, los metodos internos de la clase. p- 
rivate es una pared entre el creador de la clase y el programador cliente. Si alguien 
intenta acceder a un miembro privado, obtendra un error al compilar. protected 
actua como private, con la exception de que las clases derivadas tienen acceso a 
miembros protegidos, pero no a los privados. La herencia se explicara en breve. 


1.4. Reutilizar la implementacion 

Una vez que una clase se ha creado y probado, deberia constituir (idealmente) 
una unidad util de codigo. Sin embargo, esta reutilizacion no es tan facil de conse- 
guir como muchos esperarian; producir un buen diseno requiere experiencia y co- 
nocimientos. Pero una vez que lo tiene, pide ser reutilizado. El codigo reutilizado es 
una de las mejores ventajas de los lenguajes para programacion orientada a objetos. 

La forma mas facil de reutilizar una clase es precisamente utilizar un objeto de 
esa clase directamente, pero tambien puede colocar un objeto de esta clase dentro 
de una clase nueva. Podemos llamarlo «crear un objeto miembro». Su nueva clase 
puede estar compuesta de varios objetos de cualquier tipo, en cualquier combina¬ 
tion que necesite para conseguir la funcionalidad deseada en su nueva clase. Como 
esta componiendo una nueva clase a partir de clases existentes, este concepto se lla¬ 
ma composition (o de forma mas general, agregacion). A menudo nos referimos a la 
composition como una relation «tiene-un», como en «un coche tiene-un motor». 



Figura 1.2: Un coche tiene un motor 


(El diagrama UML anterior indica composition con el rombo relleno, lo cual im- 
plica que hay un coche. Tipicamente usare una forma mas simple: solo una linea, sin 
el rombo, para indicar una asociacion. 5 ) 

La composition es un mecanismo muy flexible. Los objetos miembro de su nueva 
clase normalmente son privados, haciendolos inaccesibles para los programadores 
clientes que estan usando la clase. Eso permite cambiar esos miembros sin perturbar 
al codigo cliente existente. Tambien puede cambiar los miembros del objeto en tiem- 

5 Normalmente esto es suficiente para la mayoria de los diagramas y no necesita especificar si esta 
usando agregacion o composicion. 
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po de ejecucion, para cambiar dinamicamente el comportamiento de su programa. 
La herencia, descrita mas adelante, no tiene esta flexibilidad dado que el compilador 
debe imponer restricciones durante la compilation en clases creadas con herencia. 

Como la herencia es tan importante en la programacion orientada a objetos, se 
suele enfatizar mucho su uso, y puede que el programador novel tenga la idea de 
que la herencia se debe usar en todas partes. Eso puede dar como resultado dise- 
nos torpes y demasiado complicados. En lugar de eso, deberia considerar primero la 
composition cuando tenga que crear nuevas clases, ya que es mas simple y flexible. 
Si acepta este enfoque, sus disenos seran mas limpios. Una vez que tenga experien- 
cia, los casos en los que necesite la herencia resultaran evidentes. 


1.5. Herencia: reutilizacion de interfaces 

En si misma, la idea de objeto es una herramienta util. Permite empaquetar datos 
y funcionalidad junto al propio concepto, ademas puede representar una idea apro- 
piada del espacio del problema en vez de estar forzado a usar el vocabulario de la 
maquina subyacente. Esos conceptos se expresan como unidades fundamentales en 
el lenguaje de programacion mediante la palabra reservada class. 

Sin embargo, es una pena tomarse tantas molestias en crear una clase y verse 
obligado a crear una mas para un nuevo tipo que tiene una funcionalidad similar. Es 
mas sencillo si se puede usar la clase existente, clonarla, y hacerle anadidos y modi- 
ficaciones a ese cion. Esto es justamente lo que hace la herencia, con la exception de 
que si cambia la clase original (llamada clase base, super o padre), el «clon» modificado 
(llamado clase derivada, heredada, sub o hija) tambien refleja esos cambios. 



Figura 1.3: subclases 


(En el diagrama UML anterior, la flecha apunta desde la clase derivada hacia la 
clase base. Como puede ver, puede haber mas de una clase derivada.) 

Un tipo hace algo mas que describir las restricciones de un conjunto de objetos; 
tambien tiene una relation con otros tipos. Dos tipos pueden tener caracteristicas y 
comportamientos en comun, pero un tipo puede contener mas caracteristicas que 
otro y tambien puede manipular mas mensajes (o hacerlo de forma diferente). La 
herencia lo expresa de forma similar entre tipos usando el concepto de tipos base 
y tipos derivados. Un tipo base contiene todas las caracteristicas y comportamien¬ 
tos compartidos entre los tipos derivados de el. Cree un tipo base para representar 
lo esencial de sus ideas sobre algunos objetos en su sistema. A partir del tipo ba¬ 
se, derive otros tipos para expresar caminos diferentes que puede realizar esa parte 
comun. 
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Por ejemplo, una maquina de reciclado de basura clasifica piezas de basura. El 
tipo base es «basura», y cada pieza de basura tiene un peso, un valor, y tambien, se 
puede triturar, fundir o descomponer. A partir de ahi, se obtienen mas tipos espe- 
dficos de basura que pueden tener caracterlsticas adicionales (una botella tiene un 
color) o comportamientos (el aluminio puede ser aplastado, el acero puede ser mag- 
netico). Ademas, algunos comportamientos pueden ser diferentes (el valor del papel 
depende del tipo y condicion). Usando la herencia, se puede construir una jerarquia 
de tipos que exprese el problema que se intenta resolver en terminos de sus tipos. 

Un segundo ejemplo es el clasico ejemplo «figura», tal vez usado en un sistema 
de diseno asistido por computador o juegos de simulacion. El tipo base es f igura, y 
cada figura tiene un tamano, un color, una posicion y asi sucesivamente. Cada figura 
se puede dibujar, borrar, mover, colorear, etc. A partir de ahi, los tipos especificos de 
figuras derivan (heredan) de ella: circulo, cuadrado, triangulo, y asi sucesivamente, 
cada uno de ellos puede tener caracterlsticas y comportamientos adicionales. Ciertas 
figuras pueden ser, por ejemplo, rotadas. Algunos comportamientos pueden ser di¬ 
ferentes, como cuando se quiere calcular el area de una figura. La jerarquia de tipos 
expresa las similitudes y las diferencias entre las figuras. 



Figura 1.4: Jerarquia de Figura 


Modelar la solucion en los mismos terminos que el problema es tremendamente 
beneficioso porque no se necesitan un monton de modelos intermedios para trans- 
formar una descripcion del problema en una descripcion de la solucion. Con objetos, 
la jerarquia de tipos es el principal modelo, lleva directamente desde la descripcion 
del sistema en el mundo real a la descripcion del sistema en codigo. Efectivamente, 
una de las dificultades que la gente tiene con el diseno orientado a objetos es que es 
demasiado facil ir desde el principio hasta el final. Una mente entrenada para buscar 
soluciones complejas a menudo se confunde al principio a causa de la simplicidad. 

Cuando se hereda de un tipo existente, se esta creando un tipo nuevo. Este nuevo 
tipo contiene no solo todos los miembros del tipo base (aunque los datos privados 
private estan ocultos e inaccesibles), sino que ademas, y lo que es mas importante, 
duplica la interfaz de la clase base. Es decir, todos los mensajes que se pueden en- 
viar a los objetos de la clase base se pueden enviar tambien a los objetos de la clase 
derivada. Dado que se conoce el tipo de una clase por los mensajes que se le pue- 
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den enviar, eso significa que la clase derivada es del mismo tipo que la clase base. En el 
ejemplo anterior, «un circulo es una figura». Esta equivalencia de tipos via herencia 
es uno de las claves fundamentales para comprender la programacion orientada a 
objetos. 

Por lo que tanto la clase base como la derivada tienen la misma interfaz, debe 
haber alguna implementacion que corresponda a esa interfaz. Es decir, debe haber 
codigo para ejecutar cuando un objeto recibe un mensaje particular. Si simplemente 
hereda de una clase y no hace nada mas, los metodos de la interfaz de la clase base 
estan disponibles en la clase derivada. Esto significa que los objetos de la clase deri¬ 
vada no solo tienen el mismo tipo, tambien tienen el mismo comportamiento, lo cual 
no es particularmente interesante. 

Hay dos caminos para diferenciar la nueva clase derivada de la clase base origi¬ 
nal. El primero es bastante sencillo: simplemente hay que anadir nuevas funciones a 
la clase derivada. Estas nuevas funciones no son parte de la interfaz de la clase base. 
Eso significa que la clase base simplemente no hace todo lo que necesitamos, por lo 
que se anaden mas funciones. Este uso simple y primitivo de la herencia es, a ve- 
ces, la solucion perfecta a muchos problemas. Sin embargo, quiza deberia pensar en 
la posibilidad de que su clase base puede necesitar tambien funciones adicionales. 
Este proceso de descubrimiento e iteracion de su diseno ocurre regularmente en la 
programacion orientada a objetos. 



Figura 1.5: Especializacion de Figura 


Aunque la herencia algunas veces supone que se van a anadir nuevas funciones 
a la interfaz, no es necesariamente cierto. El segundo y mas importante camino para 
diferenciar su nueva clase es cambiar el comportamiento respecto de una funcion de 
una clase base existente. A esto se le llama reescribir ( override ) una funcion. 
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Figura 1.6: Reescritura de metodos 


Para reescribir una funcion, simplemente hay que crear una nueva definition pa¬ 
ra esa funcion en la clase derivada. Esta diciendo, «Estoy usando la misma funcion 
de interfaz aqui, pero quiero hacer algo diferente para mi nuevo tipo». 


1.5.1. Relaciones es-un vs. es-como-un 

Hay cierta controversia que puede ocurrir con la herencia: Ja herencia deberia 
limitarse a anular solo funciones de la clase base (y no anadir nuevos metodos que 
no esten en la clase base)? Esto puede significar que el tipo derivado es exactamente 
el mismo tipo que la clase base dado que tiene exactamente la misma interfaz. Como 
resultado, se puede sustituir un objeto de una clase derivada por un objeto de la 
clase base. Se puede pensar como una sustitucion pura, y se suele llamar principio de 
sustitucion. En cierto modo, esta es la forma ideal de tratar la herencia. A menudo 
nos referimos a las relaciones entre la clase base y clases derivadas en este caso como 
una relacion es-un, porque se dice «un circulo es una figura». Un modo de probar la 
herencia es determinar si se puede considerar la relacion es-un sobre las clases y si 
tiene sentido. 

Hay ocasiones en las que se deben anadir nuevos elementos a la interfaz de un 
tipo derivado, de esta manera se amplia la interfaz y se crea un tipo nuevo. El nuevo 
tipo todavia puede ser sustituido por el tipo base, pero la sustitucion no es perfecta 
porque sus nuevas funciones no son accesibles desde el tipo base. Esta relacion se 
conoce como es-como-un; el nuevo tipo tiene la interfaz del viejo tipo, pero tambien 
contiene otras funciones, por lo que se puede decir que es exactamente el mismo. 
Por ejemplo, considere un aire acondicionado. Suponga que su casa esta conectada 
con todos los controles para refrigerar; es decir, tiene una interfaz que le permite 
controlar la temperatura. Imagine que el aire acondicionado se averia y lo reemplaza 
por una bomba de calor, la cual puede dar calor y trio. La bomba de calor es-como-un 
aire acondicionado, pero puede hacer mas cosas. Como el sistema de control de su 
casa esta disenado solo para controlar el trio, esta rentringida a comunicarse solo con 
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la parte de trio del nuevo objeto. La interfaz del nuevo objeto se ha extendido, y el 
sistema existente no conoce nada excepto la interfaz original. 



Figura 1.7: Relaciones 


Por supuesto, una vez que vea este diseno queda claro que la clase base «sistema 
de frio» no es bastante general, y se deberia renombrar a «sistema de control de tem- 
peratura», ademas tambien puede incluir calor, en este punto se aplica el principio 
de sustitucion. Sin embargo, el diagrama de arriba es un ejemplo de lo que puede 
ocurrir en el diseno y en el mundo real. 

Cuando se ve el principio de sustitucion es facil entender como este enfoque (sus¬ 
titucion pura) es la unica forma de hacer las cosas, y de hecho es bueno para que sus 
disenos funcionen de esta forma. Pero vera que hay ocasiones en que esta igualmen- 
te claro que se deben anadir nuevas funciones a la interfaz de la clase derivada. Con 
experiencia, ambos casos puede ser razonablemente obvios. 


1.6. Objetos intercambiables gracias al polimorfis¬ 
mo 

Cuando se manejan jerarquias de tipos, se suele tratar un objeto no como el tipo 
especifico si no como su tipo base. Esto le permite escribir codigo que no depende 
de los tipos especificos. En el ejemplo de la figura, las funciones manipulan figuras 
genericas sin preocuparse de si son circulos, cuadrados, triangulos, etc. Todas las 
figuras se pueden dibujar, borrar y mover, pero estas funciones simplemente envian 
un mensaje a un objeto figura, sin preocuparse de como se las arregla el objeto con 
cada mensaje. 

Semejante codigo no esta afectado por la adicion de nuevos tipos, y anadir nue- 
vos tipos es la forma mas comun de extender un programa orientado a objetos para 
tratar nuevas situaciones. Por ejemplo, puede derivar un nuevo subtipo de figura 11a- 
mado pentagono sin modificar las funciones que tratan solo con figuras genericas. 
Esta habilidad para extender un programa facilmente derivando nuevos subtipos es 
importante porque mejora enormemente los disenos al mismo tiempo que reduce el 
coste del mantenimiento del software. 
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Hay un problema, no obstante, con intentar tratar un tipo derivado como sus 
tipos base genericos (circulos como figuras, bicicletas como vehiculos, cormoranes 
como pajaros, etc). Si una funcion va a indicar a una figura generica que se dibuje 
a si misma, o a un vehiculo generico que se conduzca, o a un pajaro generico que 
se mueva, el compilador en el momento de la compilacion no sabe con precision 
que pieza del codigo sera ejecutada. Este es el punto clave - cuando el mensaje se 
envia, el programador no quiere saber que pieza de codigo sera ejecutada; la funcion 
dibu jar () se puede aplicar a un circulo, un cuadrado, o un triangulo, y el objeto 
ejecutara el codigo correcto dependiendo de tipo especifico. Si no sabe que pieza del 
codigo se ejecuta, 4 que hace? Por ejemplo, en el siguiente diagrama el objeto Cont- 
roladorDePajaro trabaja con los objetos genericos Pa jaro, y no sabe de que tipo 
son exactamente. Esto es conveniente desde la perspectiva del ControladorDeP- 
a jaro, porque no hay que escribir codigo especial para determinar el tipo exacto de 
Pajaro con el que esta trabajando, o el comportamiento del Pajaro. Entonces, <;que 
hace que cuando se invoca mover () ignorando el tipo especifico de Pajaro, puede 
ocurrir el comportamiento correcto (un Ganso corre, vuela, o nada, y un Pinguino 
corre o nada)? 


ControladorDePajar 


Pajaro 


recolocar( ) 


iQue ocurre cuando _ 

se invoca mover( )? mover( ) 


Ganso 


_i_ 

Pinguino 

mover( ) 


mover( ) 


Figura 1.8: Polimorfismo 


La respuesta es el primer giro en programacion orientada a objetos: el compilador 
no hace una llamada a la funcion en el sentido tradicional. La llamada a funcion 
generada por un compilador no-OO provoca lo que se llama una ligadura temprana 
(early binding), un termino que quiza no haya oido antes porque nunca ha pensado en 
que hubiera ninguna otra forma. Significa que el compilador genera una llamada al 
nombre de la funcion especifica, y el enlazador resuelve esta llamada con la direccion 
absoluta del codigo que se ejecutara. En POO, el programa no puede determinar la 
direccion del codigo hasta el momento de la ejecucion, de modo que se necesita algun 
otro esquema cuando se envia un mensaje a un objeto generico. 

Para resolver el problema, los lenguajes orientados a objetos usan el concepto de 
ligadura tardia (late binding). Cuando envia un mensaje a un objeto, el codigo invocado 
no esta determinado hasta el momento de la ejecucion. El compilador se asegura de 
que la funcion existe y realiza una comprobacion de tipo de los argumentos y el valor 
de retorno (el lenguaje que no realiza esta comprobacion se dice que es debilmente 
tipado), pero no sabe el codigo exacto a ejecutar. 

Para llevar a cabo la ligadura tardia, el compilador de C++ inserta un trozo espe¬ 
cial de codigo en lugar de la llamada absoluta. Este codigo calcula la direccion del 
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cuerpo de la funcion, usando informacion almacenada en el objeto (este proceso se 
trata con detalle en el Capitulo 15). De este modo, cualquier objeto se puede compor- 
tar de forma diferente de acuerdo con el contenido de este trozo especial de codigo. 
Cuando envia un mensaje a un objeto, el objeto comprende realmente que hacer con 
el mensaje. 

Es posible disponer de una funcion que tenga la flexibilidad de las propiedades 
de la ligadura tardia usando la palabra reservada virtual. No necesita entender 
el mecanismo de virtual para usarla, pero sin ella no puede hacer programacion 
orientada a objetos en C++. En C++, debe recordar anadir la palabra reservada vi¬ 
rtual porque, por defecto, los metodos no se enlazan dinamicamente. Los metodos 
virtuales le permiten expresar las diferencias de comportamiento en clases de la mis- 
ma familia. Estas diferencias son las que causan comportamientos polimorficos. 

Considere el ejemplo de la figura. El diagrama de la familia de clases (todas basa- 
das en la misma interfaz uniforme) aparecio antes en este capitulo. Para demostrar 
el polimorfismo, queremos escribir una unica pieza de codigo que ignore los detalles 
especificos de tipo y hable solo con la clase base. Este codigo esta desacoplado de la 
informacion del tipo especifico, y de esa manera es mas simple de escribir y mas facil 
de entender. Y, si tiene un nuevo tipo - un Hexagono, por ejemplo - se anade a traves 
de la herencia, el codigo que escriba funcionara igual de bien para el nuevo tipo de 
Figura como para los tipos anteriores. De esta manera, el programa es extensible. 

Si escribe una funcion C++ (podra aprender dentro de poco como hacerlo): 

void hacerTarea(FiguraS f) { 

f.borrar(); 

// ... 

f.dibujar (); 

} 


Esta funcion se puede aplicar a cualquier Figura, de modo que es independiente 
del tipo especifico del objeto que se dibuja y borra (el «&» significa «toma la direccion 
del objeto que se pasa a hacerTarea () », pero no es importante que entienda los 
detalles ahora). Si en alguna otra parte del programa usamos la funcion hacerTa¬ 
rea (): 

Circulo c; 

Triangulo t; 

Linea 1; 
hacerTarea(c); 
hacerTarea(t); 
hacerTarea(1); 


Las llamadas ahacerTareaf) funcionan bien automaticamente, a pesar del tipo 
concreto del objeto. 

En efecto es un truco bonito y asombroso. Considere la linea: 

hacerTarea(c); 

Lo que esta ocurriendo aqui es que esta pasando un Circulo a una funcion que 
espera una Figura. Como un Circulo es una Figura se puede tratar como tal por 
parte de hacerTarea (). Es decir, cualquier mensaje que pueda enviar hacerTar¬ 
ea () a una Figura, un Circulo puede aceptarlo. Por eso, es algo completamente 
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logico y seguro. 

A este proceso de tratar un tipo derivado como si fuera su tipo base se le llama 
upcasting (moldeado lmcia arriba 6 ). El nombre cast (molde) se usa en el sentido de adap- 
tar a un molde y es hacia arriba por la forma en que se dibujan los diagramas de clases 
para indicar la herencia, con el tipo base en la parte superior y las clases derivadas 
colgando debajo. De esta manera, moldear un tipo base es moverse hacia arriba por 
el diagrama de herencias: «upcasting» 



Figura 1.9: Upcasting 


Todo programa orientado a objetos tiene algun upcasting en alguna parte, por- 
que asi es como se despreocupa de tener que conocer el tipo exacto con el que esta 
trabajando. Mire el codigo de hacerTarea ( ): 

f.borrar(); 

II... 

f.dibujar(); 

Observe que no dice «Si es un Circulo, haz esto, si es un Cuadrado, haz esto 
otro, etc.». Si escribe un tipo de codigo que comprueba todos los posibles tipos que 
una Figura puede tener realmente, resultara sucio y tendra que cambiarlo cada vez 
que anada un nuevo tipo de Figura. Aqui, solo dice «Eres una figura, se que te 
puedes borrar ( ) y dibu jar () a ti misma, hazlo, y preocupate de los detalles». 

Lo impresionante del codigo en hacerTarea () es que, de alguna manera, fun- 
ciona bien. Llamar a dibu jar () para un Circulo ejecuta diferente codigo que 
cuando llama a dibu jar () para un Cuadrado o una Linea, pero cuando se envia 
el mensaje dibu jar () a un Figura anonima, la conducta correcta sucede en base 
en el tipo real de Figura. Esto es asombroso porque, como se menciono anterior- 
mente, cuando el compilador C++ esta compilando el codigo para hacerTarea () , 
no sabe exactamente que tipos esta manipulando. Por eso normalmente, es de espe- 
rar que acabe invocando la version de borrar () y dibu jar () para Figura, y no 
para el Circulo, Cuadrado, o Linea especifico. Y aun asi ocurre del modo correc- 
to a causa del polimorfismo. El compilador y el sistema se encargan de los detalles; 
todo lo que necesita saber es que esto ocurre y lo que es mas importante, como utili- 
zarlo en sus disenos. Si un metodo es virtual, entonces cuando envie el mensaje a 

6 N. de T: En el libro se utilizara el termino original en ingles debido a su uso comun, incluso en la 
literatura en Castellano. 
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un objeto, el objeto hara lo correcto, incluso cuando este involucrado el upcasting. 


1.7. Creacion y destruccion de objetos 

Tecnicamente, el dominio de la POO son los tipos abstractos de datos, la herencia 
y el polimorfismo, pero otros asuntos pueden ser al menos igual de importantes. Esta 
seccion ofrece una vision general de esos asuntos. 

Es especialmente importante la forma en que se crean y se destruyen los objetos. 
^Donde esta el dato para un objeto y como se controla la vida de este objeto? Dife- 
rentes lenguajes de programacion usan distintas filosofias al respecto. C++ adopta 
el enfoque de que el control de eficiencia es la cuestion mas importante, pero eso 
delega la eleccion al programador. Para una velocidad maxima de ejecucion, el al- 
macenamiento y la vida se determinan mientras el programa se escribe, colocando 
los objetos en la pila o en almacenamiento estatico. La pila es un area de memoria 
usada directamente por el microprocesador para almacenar datos durante la ejecu¬ 
cion del programa. A veces las variables de la pila se llaman variables automations o 
de dmbito (scoped). El area de almacenamiento estatico es simplemente un parche fijo 
de memoria alojado antes de que el programa empiece a ejecutarse. Usar la pila o 
el area de almacenamiento estatico fija una prioridad en la rapidez de asignacion y 
liberacion de memoria, que puede ser valioso en algunas situaciones. Sin embargo, 
se sacrifica flexibilidad porque se debe conocer la cantidad exacta, vida, y tipo de 
objetos mientras el programador escribe el programa. Si esta intentando resolver un 
problema mas general, como un diseno asistido por computadora, gestion de alma- 
cen, o control de trafico aereo, eso tambien es restrictivo. 

El segundo enfoque es crear objetos dinamicamente en un espacio de memoria 
llamado monttculo (heap). En este enfoque no se sabe hasta el momento de la ejecu¬ 
cion cuantos objetos se necesitan, cual sera su ciclo de vida, o su tipo exacto. Estas 
decisiones se toman de improviso mientras el programa esta en ejecucion. Si necesita 
un nuevo objeto, simplemente creelo en el monticulo cuando lo necesite, usando la 
palabra reservada new. Cuando ya no necesite ese espacio de almacenamiento, debe 
liberarlo usando la palabra reservada delete. 

Como la memoria se administra dinamicamente en tiempo de ejecucion, la canti¬ 
dad de tiempo requerido para reservar espacio en el monticulo es considerablemente 
mayor que el tiempo para manipular la pila (reservar espacio en la pila a menudo 
es una unica instruccion del microprocesador para mover el puntero de la pila hacia 
abajo, y otro para moverlo de nuevo hacia arriba). El enfoque dinamico asume que 
los objetos tienden a ser complicados, por eso la sobrecarga extra de encontrar espa¬ 
cio para alojarlos y despues liberarlos, no tiene un impacto importante en la creacion 
de un objeto. Ademas, el aumento de flexibilidad es esencial para resolver problemas 
generales de programacion. 

Hay otra cuestion, sin embargo, y es el tiempo de vida de un objeto. Si crea un 
objeto en la pila o en espacio estatico, el compilador determina cuanto tiempo dura 
el objeto y puede destruirlo automaticamente. Pero si lo crea en el monticulo, el com¬ 
pilador no tiene conocimiento de su tiempo de vida. En C++, el programador debe 
determinar programaticamente cuando destruir el objeto, y entonces llevar a cabo la 
destruccion usando la palabra reservada delete. Como alternativa, el entorno pue¬ 
de proporcionar una caracteristica llamada recolector de basura (garbage collector) que 
automaticamente descubre que objetos ya no se usan y los destruye. Naturalmente, 
escribir programas usando un recolector de basura es mucho mas conveniente, pero 
requiere que todas las aplicaciones sean capaces de tolerar la existencia del recolector 
de basura y la sobrecarga que supone. Eso no encaja en los requisitos del diseno del 
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lenguaje C++ por lo que no se incluye, aunque existen recolectores de basura para 
C++, creados por terceros. 


1.8. Gestion de excepciones: tratamiento de erro- 
res 

Desde los inicios de los lenguajes de programacion, la gestion de errores ha si- 
do uno de los asuntos mas diflciles. Es tan complicado disenar un buen esquema 
de gestion de errores, que muchos lenguajes simplemente lo ignoran, delegando el 
problema en los disenadores de la librerla, que lo resuelven a medias, de forma que 
puede funcionar en muchas situaciones, pero se pueden eludir, normalmente igno- 
randolos. El problema mas importante de la mayorla de los esquemas de gestion de 
errores es que dependen de que el programador se preocupe en seguir un convenio 
que no esta forzado por el lenguaje. Si los programadores no se preocupan, cosa que 
ocurre cuando se tiene prisa, esos esquemas se olvidan facilmente. 

La gestion de excepciones «conecta» la gestion de errores directamente en el lengua¬ 
je de programacion y a veces incluso en el sistema operativo. Una excepcion es un 
objeto que se «lanza» desde el lugar del error y puede ser «capturado» por un rna- 
nejador de excepcion apropiado disenado para manipular este tipo particular de error. 
Es como si la gestion de errores fuera una ruta de ejecucion diferente y paralela que 
se puede tomar cuando las cosas van mal. Y como usa un camino separado de eje¬ 
cucion, no necesita interferir con el codigo ejecutado normalmente. Eso hace que el 
codigo sea mas simple de escribir ya que no se fuerza al programador a comprobar 
los errores constantemente. Ademas, una excepcion no es lo mismo que un valor de 
error devuelto por una funcion o una bandera fijada por una funcion para indicar 
una condicion de error, que se puede ignorar. Una excepcion no se puede ignorar, de 
modo que esta garantizado que habra que tratarla en algun momento. Finalmente, 
las excepciones proporcionan una forma para recuperar una situacion consistente. 
En lugar de salir simplemente del programa, a menudo es posible arreglar las cosas 
y restaurar la ejecucion, lo que produce sistemas mas robustos. 

Merece la pena tener en cuenta que la gestion de excepciones no es una caracte- 
rlstica orientada a objetos, aunque en lenguajes orientados a objetos las excepciones 
normalmente se representan con objetos. La gestion de excepciones existla antes que 
los lenguajes orientados a objetos. 

En este Volumen se usa y explica la gestion de excepciones solo por encima; el 
Volumen 2 (disponible en www.BruceEckel.com) cubre con mas detalle la gestion de 
excepciones. 


1.9. Analisis y diseno 

El paradigma orientado a objetos es una nueva forma de pensar sobre progra¬ 
macion y mucha gente tiene problemas la primera vez que escucha como se aborda 
un proyecto POO. Una vez que se sabe que, supuestamente, todo es un objeto, y co¬ 
mo aprender a pensar al estilo orientado a objetos, puede empezar a crear «buenos» 
disenos que aprovechen las ventajas de todos los beneficios que ofrece la POO. 

Un metodo (llamado a menudo metodologia) es un conjunto de procesos y heu- 
risticas usados para tratar la complejidad de un problema de programacion. Desde 
el comienzo de la programacion orientada a objetos se han formulado muchos me- 
todos. Esta seccion le dara una idea de cual es el objetivo que se intenta conseguir 
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cuando se usa una metodologia. 

Especialmente en POO, la metodologia es un campo de muchos experimentos, 
asi que antes de elegir un metodo, es importante que comprenda cual es el problema 
que resuelve. Eso es particularmente cierto con C++, en el que el lenguaje de progra- 
macion pretende reducir la complejidad (comparado con C) que implica expresar un 
programa. De hecho, puede aliviar la necesidad de metodologias aun mas complejas. 
En cambio, otras mas simples podrian ser suficientes en C++ para muchos tipos de 
problemas grandes que podria manejar usando metodologias simples con lenguajes 
procedurales. 

Tambien es importante darse cuenta de que el termino «metodologia» a menudo 
es demasiado grande y prometedor. A partir de ahora, cuando disene y escriba un 
programa estara usando una metodologia. Puede ser su propia metodologia, y pue¬ 
de no ser consciente, pero es un proceso por el que pasa cuando crea un programa. 
Si es un proceso efectivo, puede que solo necesite un pequeno ajuste para que fun- 
cione con C++. Si no esta satisfecho con su productividad y con el camino que sus 
programas han tornado, puede considerar adoptar un metodo formal, o elegir trozos 
de entre muchos metodos formales. 

Mientras pasa por el proceso de desarrollo, el uso mas importante es este: no per- 
derse. Eso es facil de hacer. La mayoria de los analisis y metodos de diseno pretenden 
resolver los problemas mas grandes. Recuerde que la mayoria de los proyectos no 
encajan en esta categoria, normalmente puede tener un analisis y diseno exitoso con 
un subconjunto relativamente pequeno de lo que recomienda el metodo 7 . Pero mu¬ 
chos tipos de procesos, sin importar lo limitados que sean, generalmente le ofreceran 
un camino mucho mejor que simplemente empezar a codificar. 

Tambien es facil quedarse estancado, caer en andlisis-pardlisis, donde sentira que 
no puede avanzar porque en la plataforma que esta usando no esta especificado ca- 
da pequeno detalle. Recuerde, no importa cuanto analisis haga, hay algunas cosas 
sobre el sistema que no se revelan hasta el momento del diseno, y mas cosas que no 
se revelaran hasta que este codificando, o incluso hasta que el programa este funcio- 
nando. Por eso, es crucial mo verse bastante rapido durante del analisis y diseno, e 
implementar un test del sistema propuesto. 

Este punto merece la pena enfatizarlo. Debido a nuestra experiencia con los len¬ 
guajes procedurales, es encomiable que un equipo quiera proceder con cuidado y en- 
tender cada pequeno detalle antes de pasar al diseno y a la implementacion. Desde 
luego, cuando crea un SGBD (Sistema Gestor de Bases de Datos), conviene entender 
la necesidad de un cliente a fondo. Pero un SGBD esta en una clase de problemas que 
son muy concretos y bien entendidos; en muchos programas semejantes, la estructu- 
ra de la base de datos es el problema que debe afrontarse. El tipo de problema de pro- 
gramacion tratado en este capitulo es de la variedad «comodin» (con mis palabras), 
en el que la solucion no es simplemente adaptar una solucion bien conocida, en cam¬ 
bio involucra uno o mas «factores comodin» -elementos para los que no hay solucion 
previa bien entendida, y para los que es necesario investigar 8 . Intentar analizar mi- 
nuciosamente un problema comodin antes de pasar al diseno y la implementacion 
provoca un analisis-paralisis porque no se tiene suficiente informacion para resolver 
este tipo de problema durante la fase de analisis. Resolver estos problemas requiere 


7 Un ejemplo excelente es UML Distilled, de Martin Fowler (Addison-Wesley 2000), que reduce el, a 
menudo, insoportable proceso UML a un subconjunto manejable. 

8 Mi regia general para el calculo de semejantes proyectos: Si hay mas de un comodin, no intente 
planear cuanto tiempo le llevara o cuanto costara hasta que haya creado un prototipo funcional. Tambien 
hay muchos grados de libertad. 
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interaction a traves del ciclo completo, y eso requiere comportamientos arriesgados 
(lo cual tiene sentido, porque esta intentando hacer algo nuevo y los beneficios po- 
tenciales son mayores). Puede parecer que el riesgo esta compuesto por «prisas» en 
una implementacion preliminar, pero en cambio puede reducir el riesgo en un pro- 
yecto comodin porque esta descubriendo pronto si es viable un enfoque particular 
para el problema. El desarrollo del producto es gestion de riesgos. 

A menudo se propone que «construya uno desechable». Con la POO, todavia 
debe andar parte de este camino, pero debido a que el codigo esta encapsulado en 
clases, durante la primera iteracion inevitablemente producira algunos disenos de 
clases utiles y desarrollara algunas ideas validas sobre el diseno del sistema que 
no necesariamente son desechables. De esta manera, la primera pasada rapida al 
problema no produce solo informacion critica para la siguiente iteracion de analisis, 
diseno, e implementacion, sino que ademas crea el codigo base para esa iteracion. 

Es decir, si esta buscando una metodologia que contenga detalles tremendos y 
sugiera muchos pasos y documentos, es aun mas dificil saber cuando parar. Tenga 
presente lo que esta intentando encontrar: 

1. uales son los objetos? (yComo divide su proyecto en sus partes componen- 
tes?) 

2. ,;Cuales son sus interfaces? (yQue mensajes necesita enviar a otros objetos?) 

Si solo cuenta con los objetos y sus interfaces, entonces puede escribir un progra- 
ma. Por varias razones podria necesitar mas descripciones y documentos, pero no 
puede hacerlo con menos. 

El proceso se puede realizar en cinco fases, y una fase 0 que es simplemente el 
compromiso inicial de usar algun tipo de estructura. 



1.9.1. Fase 0: Hacer un plan 

Primero debe decidir que pasos va a dar en su proceso. Parece facil (de hecho, to- 
do esto parece facil) y sin embargo la gente a menudo no toma esta decision antes de 
ponerse a programar. Si su plan es «ponerse directamente a programar», de acuer- 
do (a veces es adecuado cuando es un problema bien conocido). Al menos estara de 
acuerdo en que eso es el plan. 

Tambien debe decidir en esta fase si necesita alguna estructura de proceso adicio- 
nal, pero no las nueve yardas completas. Bastante comprensible, algunos programa- 
dores prefieren trabajar en «modo vacaciones» en cuyo caso no se impone ninguna 
estructura en el proceso de desarrollo de su trabajo; «Se hara cuando se haga». Eso 
puede resultar atractivo durante un tiempo, pero se ha descubierto que tener unos 
pocos hitos a lo largo del camino ayuda a enfocar e impulsar sus esfuerzos en torno a 
esos hitos en lugar de empezar a atascarse con el unico objetivo de «finalizar el pro- 
yecto». Ademas, divide el proyecto en piezas mas pequenas y hace que de menos 
miedo (y ademas los hitos ofrecen mas oportunidades para celebraciones). 

Cuando empece a estudiar la estructura de la historia (por eso algun dia escribire 
una novela) inicialmente me resistia a la idea de una estructura, sentia que cuan¬ 
do escribia simplemente permitia que fluyera en la pagina. Pero mas tarde me di 
cuenta de que cuando escribo sobre computadoras la estructura es bastante clara, 
pero no pienso mucho sobre ello. Pero aun asi estructuro mi trabajo, aunque solo 
semi-inconscientemente en mi cabeza. Si aun piensa que su plan es solo ponerse a 
codificar, de algun modo, usted pasara por las posteriores fases mientras pregunta y 
responde ciertas cuestiones. 


18 
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Declaration de objetivos 

Cualquier sistema construido, no importa cuan complicado sea, tiene un proposi- 
to fundamental, el negocio que hay en el, la necesidad basica que satisface. Si puede 
ver la interfaz de usuario, el hardware o los detalles especificos del sistema, los algo- 
ritmos de codification y los problemas de eficiencia, finalmente encontrara el nucleo 
de su existencia, simple y sencillo. Como el ast llamado concepto de alto nivel de una 
pelicula de Hollywood, puede describirlo en una o dos frases. Esta descripcion pura 
es el punto de partida. 

El concepto de alto nivel es bastante importante porque le da el tono a su proyec- 
to; es una declaration de principios. No tiene porque conseguirlo necesariamente la 
primera vez (podria tener que llegar a una fase posterior del proyecto antes de tener- 
lo completamente claro), pero siga intentandolo hasta que lo consiga. Por ejemplo, 
en un sistema de control de trafico aereo puede empezar con un concepto de alto 
nivel centrado en el sistema que esta construyendo: «E1 programa de la torre sigue 
la pista a los aviones». Pero considere que ocurre cuando adapta el sistema para un 
pequeno aeropuerto; quiza solo haya un controlador humano o ninguno. Un modelo 
mas util no se preocupara de la solution que esta creando tanto como la descripcion 
del problema: «Llega un avion, descarga, se revisa y recarga, y se marcha». 


1.9.2. Fase 1: ^Que estamos haciendo? 

En la generation previa de diseno de programas (llamado diseno procedural), esto 
se llamaba «crear el analisis de requisites y especificacion del sistema». Estos, por supues- 
to, eran lugares donde perderse; documentos con nombres intimidantes que podrian 
llegar a ser grandes proyectos en si mismos. Sin embargo, su intention era buena. El 
analisis de requisitos dice: «Haga una lista de las directrices que usara para saber 
cuando ha hecho su trabajo y el cliente estara satisfecho». La especificacion del siste¬ 
ma dice: «Hay una descripcion de lo que hara el programa (no como) por satisfacer los 
requisitos». El analisis de requisitos es realmente un contrato entre usted y el cliente 
(incluso si el cliente trabaja dentro de su compahia o es algun otro objeto o sistema). 
Las especificaciones del sistema son una exploration de alto nivel del problema y en 
algun sentido un descubrimiento de si se puede hacer y cuanto se tardara. Dado que 
ambos requeriran consenso entre la gente (y porque suelen cambiar todo el tiempo), 
creo que es mejor mantenerlos todo lo escueto posible -en el mejor de los casos, lis- 
tas y diagramas basicos- para ahorrar tiempo. Podria tener otras restricciones que 
le exijan ampliarla en documentos mas grandes, pero manteniendo el documento 
initial pequeno y conciso, puede crearse en algunas sesiones de tormentas de ideas 
de grupo con un lider que cree la descripcion dinamicamente. Esto no solo solicita 
participation de todos, tambien fomenta aprobacion inicial y llegar a acuerdos entre 
todos. Quiza lo mas importante sea empezar el proyecto con mucho entusiasmo. 

Es necesario no perder de vista lo que esta intentando conseguir en esta fase: 
determinar el sistema que se supone que quiere hacer. La herramienta mas valiosa 
para eso es una coleccion de los llamados «casos de uso». Los casos de uso iden- 
tifican caracteristicas clave en el sistema que pueden revelar algunas de las clases 
fundamentals que se usaran. En esencia son respuestas descriptivas a preguntas 
como: 9 : 

1. «^Quien usara el sistema?» 

2. «^Que pueden hacer estos actores con el sistema?» 

9 Gracias a James H Jarrett por su ayuda. 
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3. «^Como puede este actor hacer eso con este sistema?» 

4. «^Como podria alguien mas hacer este trabajo si alguien mas estuviera hacien- 
dolo, o si el mismo actor tuviera un objetivo diferente?» (para revelar variacio- 
nes). 

5. «^Que problemas podrian ocurrir mientras hace esto con el sistema?» (para 
revelar excepciones). 

Si esta disenando un cajero automatico, por ejemplo, el caso de uso para un aspec- 
to particular de la funcionalidad del sistema es poder describir que hace el contes- 
tador automatico en todas las situaciones posibles. Cada una de esas «situaciones» 
se denomina escenario, y se puede considerar que un caso de uso es una coleccion 
de escenarios. Puede pensar en un escenario como una pregunta que comienza con: 
«^Que hace el sistema si...?» Por ejemplo, «<j,Que hace el cajero automatico si un clien- 
te ingresa un cheque dentro de las 24 horas y no hay suficiente en la cuenta para 
proporcionar la nota para satisfacer el cargo?» 

Los diagramas de caso de uso son intencionadamente simples para impedir que 
se atasque con los detalles de implementacion del sistema demasiado pronto: 



o 



Cajero 


Figura 1.10: Diagramas de casos de uso 


Cada monigote representa un «actor», que tipicamente es un humano o algun 
otro tipo de agente libre. (Incluso puede ser otro sistema de computacion, como es 
el caso del «ATM»). La caja representa el limite del sistema. Las elipses representan 
los casos de uso, los cuales son descripciones de trabajo valido que se puede llevar 
a cabo con el sistema. Las lineas entre los actores y los casos de uso representan las 
interacciones. 

No importa como esta implementado realmente el sistema, mientras se lo parezca 
al usuario. 

Un caso de uso no necesita ser terriblemente complejo, incluso si el sistema sub- 
yacente es complejo. Lo unico que se persigue es mostrar el sistema tal como aparece 
ante el usuario. Por ejemplo: 



//' 
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o 


Invernadero 


Jardinero 


A 



Figura 1.11: Un ejemplo de caso de uso 


Los casos de uso producen las especificaciones de requisitos determinando todas 
las interacciones que el usuario puede tener con el sistema. Intente descubrir una 
serie completa de casos de uso para su sistema, y una vez que lo haya hecho tendra 
lo esencial sobre lo que se supone que hace su sistema. Lo bueno de centrarse en 
casos de uso es que siempre le lleva de vuelta a lo esencial y le mantiene alejado 
de los asuntos no criticos para conseguir terminar el trabajo. Es decir, si tiene una 
serie completa de casos de uso puede describir su sistema y pasar a la siguiente fase. 
Probablemente no lo hara todo perfectamente en el primer intento, pero no pasa 
nada. Todo le sera revelado en su momento, y si pide una especificacion del sistema 
perfecta en este punto se atascara. 

Si se ha atascado, puede reactivar esta fase usando una herramienta tosca de 
aproximacion: describir el sistema en pocos parrafos y despues buscar sustantivos y 
verbos. Los nombres pueden sugerir actores, contexto del caso de uso (ej. «lobby»), 
o artefactos manipulados en el caso de uso. Los verbos pueden sugerir interaccion 
entre actores y casos de uso, y pasos especificos dentro del caso de uso. Ademas 
descubrira que nombres y verbos producen objetos y mensajes durante la fase de 
diseno (y observe que los casos de uso describen interacciones entre subsistemas, asi 
que la tecnica «nombre y verbo» solo se puede usar como una herramienta de lluvia 
de ideas puesto que no genera casos de uso) 10 . 

El limite entre un caso de uso y un actor puede mostrar la existencia de una 
interfaz de usuario, pero no la define. Si le interesa el proceso de definicion y creacion 
de interfaces de usuario, vea Software for Use de Larry Constantine y Lucy Lockwood, 
(Addison Wesley Longman, 1999) o vaya a www.ForUse.com. 

Aunque es un arte oscuro, en este punto es importante hacer algun tipo de esti¬ 
macion de tiempo basica. Ahora tiene una vision general de que esta construyendo 
asi que probablemente sera capaz de tener alguna idea de cuanto tiempo llevara. 
Aqui entran en juego muchos factores. Si hace una estimacion a largo plazo entonces 
la compania puede decidir no construirlo (y usar sus recursos en algo mas razonable 
-eso es bueno). O un gerente puede tener ya decidido cuanto puede durar un pro- 
yecto e intentar influir en su estimacion. Pero es mejor tener una estimacion honesta 
desde el principio y afrontar pronto las decisiones dificiles. Ha habido un monton 
de intentos de crear tecnicas de estimacion precisas (como tecnicas para predecir la 
bolsa), pero probablemente la mejor aproximacion es confiar en su experiencia e in- 
tuicion. Utilice su instinto para predecir cuanto tiempo llevara tenerlo terminado, 
entonces multiplique por dos y anada un 10%. Su instinto visceral probablemente 
sea correcto; ipuede conseguir algo contando con este tiempo. El «doble» le permitira 
convertirlo en algo decente, y el 10% es para tratar los refinamientos y detalles fi- 


10 Puede encontar mas information sobre casos de uso en Applying Use Cases de Schneider & Winters 
(Addison-Wesley 1998) y Use Case Driven Object Modeling with UML de Rosenberg (Addison-Wesley 1999). 


















Volumenl" — 2012/1/12 — 13:52 — page 22 — #60 


Capitulo 1. Introduction a los Objetos 


nales 11 . Sin embargo, usted quiere explicarlo, y a pesar de quejas y manipulaciones 
que ocurren cuando publique la estimation, parece que esta regia funciona. 


1.9.3. Fase 2: ^Como podemos construirlo? 

En esta fase debe aparecer un diseno que describa que clases hay y como interac- 
tuan. Una tecnica excelente para determinar clases es la tarjeta Clase-Responsabilidad- 
Colaboracidn ( Class-Responsibility-Collaboration ) o CRC. Parte del valor de esta herra- 
mienta es que es baja-tecnologta: empieza con una coleccion de 3 a 5 tarjeta en bianco, 
y se escribe sobre ellas. Cada tarjeta representa una unica clase, y en ella se escribe: 

1. El nombre de la clase. Es importante que el nombre refleje la esencia de lo que 
hace la clase, asi todo tiene sentido con un simple vistazo. 

2. Las «responsabilidades» de la clase: que debe hacer. Trpicamente se puede re- 
sumir por la misma declaration de las funciones miembro o metodos (ya que 
esos nombres pueden ser descritos en un buen diseno), pero no descarte otras 
notas. Si necesita hacer una selection previa, mire el problema desde un punto 
de vista de programador perezoso: ^Que objetos quiere que aparezcan por arte 
de magia para resolver su problema? 

3. Las «colaboraciones» de la clase: ^que otras clases interactuan con esta? «Inter- 
accion» es un termino amplio a proposito; puede significar agregacion o sim- 
plemente que algun otro objeto que lleva a cabo servicios para un objeto de la 
clase. Las colaboraciones deberian considerar tambien la audiencia para esta 
clase. Por ejemplo, si crea una clase Petardo, ^quien va a observarlo, un Q- 
ulmico o un Espectador? El primero puede querer saber que componentes 
quimicos se han usado en su construction, y el ultimo respondera a los colores 
y figuras que aparezcan cuando explote. 

Puede creer que las fichas pueden ser mas grandes por toda la information que 
pondra en ellas, pero son pequenas a proposito, no solo para que las clases se man- 
tengan pequenas tambien para evitar tener que manejar demasiados detalles dema- 
siado pronto. Si no puede apuntar todo lo que necesita saber sobre una clase en una 
ficha pequena, la clase es demasiado compleja (a esta poniendo demasiados detalles, 
o deberia crear mas de una clase). La clase ideal se entiende con un vistazo. La idea 
de las fichas CRC es ayudarle a realizar un acercamiento con un primer corte del 
diseno y que pueda obtener una vision global y despues refinar su diseno. 

Uno de los mayores beneficios de las tarjetas CRC es la comunicacion. Se hace 
mejor en tiempo-real, en grupo, sin computadores. Cada persona es responsable de 
varias clases (que al principio no tienen nombres ni otra information). Haga una si¬ 
mulation en vivo resolviendo un escenario cada vez, decidiendo que mensajes envia 
a varios objetos para satisfacer las necesidades de cada escenario. Al pasar por este 
proceso, descubrira las clases que necesita con sus responsabilidades y colaboracio¬ 
nes, rellene las tarjetas del mismo modo. Cuando haya pasado por todos los casos 
de uso, deberia disponer de un primer corte bastante completo su diseno. 

Antes de empezar a usar fichas CRC, las mayoria de las experiencias de consulto- 
ria exitosas las tuve cuando me enfrentaba con un diseno inicial complicado estando 

11 Ultimamente mi idea respeto a esto ha cambiado. Doblar y anadir un 10% puede darle una esti¬ 
macion bastante acertada (asumiendo que no hay demasiados factores comodin), pero debe trabajar con 
bastante diligencia para acabar a tiempo. Si realmente quiere tiempo para hacerlo de forma elegante y 
estar orgulloso del proceso, el multiplicador correcto es mas bien tres o cuatro veces, creo yo. 
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al frente de un equipo, que no habia construido un proyecto POO antes, y dibujando 
objetos en un pizarra blanca. Hablabamos sobre como los objetos deberian comuni- 
carse unos con otros, y borrabamos algunos de ellos para reemplazarlos por otros 
objetos. Efectivamente, yo gestionaba todas las«tarjetas CRC» en la pizarra. Real- 
mente, el equipo (que conoda lo que el proyecto se suponia tenia que hacer) creo 
el diseno; ellos «poseian» el diseno en lugar de tener que darselo. Todo lo que yo 
hacia era guiar el proceso haciendo las preguntas correctas, poniendo a prueba los 
suposiciones, y llevando la retroalimentacion del equipo para modificar esas supo- 
siciones. La verdadera belleza del proceso era que el equipo aprendia como hacer 
disenos orientado a objetos no revisando ejemplos abstractos, sino trabajando sobre 
un diseno que era mas interesante para ellos en ese momento: los suyos. 

Una vez que tenga con una serie de tarjetas CRC, quiza quiera crear una descrip- 
cion mas formal de su diseno usando UML 12 . No necesita usar UML, pero puede 
servirle de ayuda, especialmente si quiere poner un diagrama en la pared para que 
todo el mundo lo tenga en cuenta, lo cual es una buena idea. Una alternativa a UML 
es una description textual de los objetos y sus interfaces, o, dependiendo de su len- 
guaje de programacion, el propio codigo 13 . 

UML tambien proporciona una notation de diagramas adicional para describir 
el modelo dinamico de su sistema. Eso es util en situaciones en las que las transicio- 
nes de estado de un sistema o subsistema son bastante mas dominantes de lo que 
necesitan sus propios diagramas (como en un sistema de control). Tambien puede 
necesitar describir las estructuras de datos, para sistemas o subsistemas en los que 
los propios datos son un factor dominante (como una base de datos). 

Sabra que esta haciendo con la fase 2 cuando haya descrito los objetos y sus in¬ 
terfaces. Bien, en muchos de ellos hay algunos que no se pueden conocer hasta la 
fase 3. Pero esta bien. Todo lo que le preocupa es que eventualmente descubra todo 
sobre sus objetos. Es bueno descubrirlos pronto pero la POO proporciona suficiente 
estructura de modo que no es grave si los descubre mas tarde. De hecho, el diseno 
de un objeto suele ocurrir en cinco etapas, durante todo el proceso de desarrollo del 
programa. 


Las cinco etapas del diseno de objetos 

La vida del diseno de un objeto no se limita a la escritura del programa. En cam- 
bio, el diseno de un objeto ocurre en una secuencia de etapas. Es util tener esta pers- 
pectiva porque no deberia esperar alcanzar la perfection enseguida; en lugar de eso, 
se dara cuenta que entender lo que hace un objeto y a que se deberia que ocurre con 
el tiempo. Esta vista tambien se aplica al diseno de varios tipos de programas; el pa¬ 
tron para un tipo particular de programas surge a fuerza de pelearse una y otra vez 
con ese problema (los Patrones de Diseno se desarrollan en el Volumen 2). Los objetos, 
tambien, tienen sus patrones que surgen del entendimiento, uso y reutilizacion. 


1. Descubrimiento de objetos. Esta etapa ocurre durante el analisis initial de un 
programa. Los objetos pueden descubrirse viendo los factores externos y los 
limites, duplication de elementos en el sistema, y las unidades conceptuales 
mas pequenas. Algunos objetos son obvios si se dispone de un conjunto de 
librerias de clases. Las partes comunes entre clases pueden sugerir clases base 
y herencia que pueden aparecer pronto, o mas tarde en el proceso de diseno. 


12 Para novatos, recomiendo el mencionado UML Distilled. 

13 Python (www.python.org) suele utilizarse como «pseudocodigo ejecutable». 
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2. Montaje de objetos. Si esta construyendo un objeto descubrira la necesidad de 
nuevos miembros que no aparecen durante la fase de descubrimiento. Las ne- 
cesidades internas del objeto pueden requerir otras clases que le den soporte. 

3. Construction del sistema. Una vez mas, pueden aparecer mas requisitos para 
un objeto a lo largo de esta etapa. Conforme aprende, evoluciona sus objetos. 
La necesidad de comunicacion e interconexion con otros objetos en el sistema 
puede cambiar las necesidades de sus clases o requerir clases nuevas. Por ejem- 
plo, puede descubrir la necesidad de clases utileria o ayudantes (helper), como 
una lista enlazada, que contienen o no una pequena informacion de estado y 
que simplemente ayudan a la funcion de otras clases. 

4. Extension del sistema. Cuando anada nuevas caracteristicas a un sistema pue¬ 
de descubrir que su diseno previo no soportaba extensiones sencillas del siste¬ 
ma. Con esta nueva informacion, puede reestructurar partes del sistema, posi- 
blemente anadiendo nuevas clases o jerarquia de clases. 

5. Reutilizacion de objetos. Esta es la verdadera prueba de estres para una clase. Si 
alguien intenta reutilizarla en una situation completamente nueva, probable- 
mente descubrira algunos defectos. Si cambia una clase para adaptarla a nue¬ 
vos programas, los principios generales de la clase se veran mas claros, hasta 
que consiga un tipo verdaderamente reutilizable. Sin embargo, no espere que 
muchos objetos del diseno de un sistema sean reutilizables -es perfectamente 
aceptable que la mayor parte de los objetos sean especificos para el sistema. Los 
tipos reutilizables tienden a ser menos comunes, y deben resolver problemas 
mas generales para ser reutilizables. 

Directrices para desarrollo de objetos 

Estas etapas sugieren algunas directrices cuando se piensa sobre el desarrollo de 
clases: 


1. Permita que un problema especifico de lugar a una clase, despues deje que la 
clase crezca y madure durante la solution de otros problemas. 

2. Recuerde, descubrir las clases que necesita (y sus interfaces) supone la mayor 
parte del diseno del sistema. Si ya tenia esas clases, sera un proyecto facil. 

3. No se esfuerce por saber todo desde el principio; aprenda conforme avanza. 
Ocurrira asi de todos modos. 

4. Comience a programar; consiga tener algo funcionando para poder aprobar o 
desaprobar su diseno. No tenga miedo a que acabe haciendo codigo procedural 
espagueti -las clases dividen el problema y ayudan a controlar la anarquia y la 
entropia. Las clases malas no estropean las buenas. 

5. Mantengalo simple. Pequenos objetos claros con utilidades obvias son mejores 
que grandes interfaces complicadas. Cuando aparezcan los puntos de decision, 
aplique el principio de la Navaja de Occam: Considere las alternativas y elija 
la mas simple, porque las clases simples casi siempre son mejores. Empiece 
con clases pequenas y sencillas, y podra ampliar la interfaz cuando la entienda 
mejor, pero cuando esto ocurra, sera dificil eliminar elementos de la clase. 
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1.9.4. Fase 3: Construir el nucleo 

Esta es la conversion inicial desde el diseno rudo al cuerpo del codigo compilable 
y ejecutable que se puede probar, y que aprobara y desaprobara su arquitectura. No 
es un proceso en un solo paso, mas bien es el principio de una serie de pasos que 
iterativamente construiran el sistema, como vera en la fase 4. 

Su objetivo es encontrar el nucleo de la arquitectura de su sistema que hay que 
implementar para generar un sistema funcional, sin importar lo incompleto que este 
el sistema en la pasada inicial. Esta creando una estructura que se puede construir 
con mas iteraciones. Tambien esta llevando a cabo la primera de muchas integracio- 
nes del sistema y pruebas, y dando a los clientes realimentacion sobre como seran 
y como progresan sus sistemas. Idealmente, tambien expone algunos de los ries- 
gos crlticos. Probablemente descubrira cambios y mejoras que se pueden hacer en 
la arquitectura original - cosas que podrla no haber aprendido sin implementar el 
sistema. 

Parte de la construccion del sistema es la dosis de realidad que se obtiene al pro¬ 
bar su analisis de requisitos y su especificacion del sistema (existe de cualquier for¬ 
ma). Asegurese de que sus pruebas verifican los requisitos y los casos de uso. Cuan- 
do el nucleo de su sistema sea estable, estara preparado para progresar y anadir mas 
funcionalidad. 


1.9.5. Fase 4: Iterar los casos de uso 

Una vez que la estructura del nucleo esta funcionando, cada conjunto de carac- 
terlsticas que anade es un pequeno proyecto en st mismo. Anada una coleccion de 
caracterlsticas durante cada iteration, un periodo razonablemente corto de desarro- 
llo. 

^Como de grande es una iteracion? Idealmente, cada iteracion dura unas tres se- 
manas (puede cambiar dependiendo del lenguaje de implementation). Al final de 
ese periodo, tendra un sistema probado e integrado con mas funcionalidades de las 
que tenia antes. Pero lo que es particularmente interesante son las bases de la ite¬ 
racion: un unico caso de uso. Cada caso de uso es un paquete de funcionalidades 
relacionadas que se puede construir en su sistema de una vez, a lo largo de una ite¬ 
racion. No solo le da una mejor idea de que alcance deberia tener, tambien le da mas 
valor a la idea un caso de uso, ya que el concepto no se descarta despues del analisis 
y diseno, sino que es una unidad fundamental de desarrollo durante el proceso de 
construccion de software. 

Se deja de iterar cuando se consigue la funcionalidad deseada o se acaba el plazo 
impuesto y el cliente esta satisfecho con la version actual. (Recuerde, el software es 
una subscription de negocios). Como el proceso es iterativo, tiene muchas oportuni- 
dades para enviar un producto en lugar de un simple punto final; los proyectos de 
software libre trabajan exclusivamente en un entorno iterativo con alta realimenta¬ 
cion, que es precisamente la clave de su exito. 

Un proceso de desarrollo iterativo es valioso por muchas razones. Puede mos- 
trar y resolver pronto riesgos criticos, los clientes tienen abundantes oportunidades 
de cambiar sus opiniones, la satisfaction del programador es mas alta, y el proyecto 
puede dirigirse con mas precision. Pero un beneficio adicional importante es la reali¬ 
mentacion para los clientes, los cuales pueden ver en el estado actual del producto 
exactamente donde se encuentra todo. Esto puede reducir o eliminar la necesidad de 
abrumadoras reuniones de control y aumentar la confianza y el apoyo de los clientes. 
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1.9.6. Fase 5: Evolution 

Este es el punto en el ciclo de desarrollo que se conoce tradicionalmente como 
«mantenimiento», un termino amplio que puede significar de todo, desde «con- 
seguir que funcione como se supone que debio hacerlo desde el principio» hasta 
«anadir caracteristicas que el cliente olvido mencionar» pasando por el tradicional 
«arreglar errores que han ido apareciendo» y «anadir nuevas caracteristicas segun se 
presentan las necesidades». Se han aplicado algunas ideas equivocadas al termino 
«mantenimiento» que se ha tornado en calidad de pequeno engano, en parte porque 
sugiere que realmente ha construido un programa primitivo y todo lo que necesita 
hacer es cambiar partes, engrasarlo, e impedir que se oxide. Quiza haya un termino 
mejor para describir esa tarea. 

Yo usare el termino evolution 14 . Es decir, «no podra hacerlo bien la primera vez, 
pero le dara la oportunidad de aprender y volver atras y hacer cambios». Puede que 
necesite hacer muchos cambios hasta que aprenda y entienda el problema con ma¬ 
yor profundidad. La elegancia que obtendra si evoluciona hasta hacerlo bien valdra 
la pena, tanto a corto como a largo plazo. La evolucion es donde su programa pasa 
de bueno a fenomenal, y donde estos usos, que realmente no entiende en un pri¬ 
mer momento, pasan a ser mas claros despues. Es tambien donde sus clases pueden 
evolucionar de un uso de unico-proyecto a recursos reutilizables. 

«Hacerlo bien» no significa solo que el programa funcione segun los requisitos 
y los casos de uso. Significa que la estructura interna del codigo tiene sentido, y 
parece que encaja bien, sin sintaxis dificil, objetos sobredimensionados, o pedazos 
de codigo desgarbados. Ademas, debe tener la sensacion de que la estructura del 
programa sobrevivira a los cambios que inevitablemente habra durante su ciclo de 
vida, y estos cambios pueden hacerse facil y limpiamente. No es una tarea sencilla. 
No solo debe entender lo que esta construyendo, sino tambien como evolucionara el 
programa (lo que yo llamo el vector de cambio 15 . Afortunadamente, los lenguajes de 
programacion orientados a objetos son particularmente adecuados para dar soporte 
a este tipo de modificaciones continuas - los limites creados por los objetos son los 
que tienden a conservar la estructura frente a roturas. Tambien le permiten hacer 
cambios - algunos pueden parecer drasticos en un programa procedural - sin causar 
terremotos en todo su codigo. En realidad, el soporte para la evolucion puede que 
sea el beneficio mas importante de la POO. 

Con la evolucion, el programador crea algo que al menos se aproxima a lo que 
piensa que esta construyendo, y luego busca defectos, lo compara con sus requisitos 
y ve lo que falta. Entonces puede volver y arreglarlo redisenando y re-implementando 
las porciones del programa que no funcionen bien 16 . Realmente puede necesitar re¬ 
solver el problema, o un aspecto del mismo, varias veces antes de dar con la solucion 
correcta. (Un estudio de los Patrones de Diseno, descrito en el Volumen 2, normalmen- 
te resulta util aqui). 

La evolucion tambien ocurre cuando construye un sistema, ve que encaja con 

14 Por lo menos un aspecto de evolucion se explica en el libro Refactoring: improving the design of existing 
code (Addison-Wesley 1999) de Martin Fowler. Tenga presente que este libro usa exlusivamente ejemplos 
en Java. 

15 Este termino se explica en el capitulo Los patrones de diseno en el Volumen 2 

16 Esto es algo como «prototipado rapido», donde se propone construir un borrador de la version 
rapida y sucia que se puede utilizar para aprender sobre el sistema, y entonces puede tirar su prototipo y 
construir el bueno. El problema con el prototipado rapido es que la gente no tiro el prototipo, y construyo 
sobre el. Combinado con la falta de estructura en la programacion procedural, esto producia a menudo 
sistemas desordenados que eran dificiles de mantener. 













Volumenl" — 2012/1/12 — 13:52 — page 27 — #65 


1.10. Programacion Extrema 


sus requisites, y entonces descubre que no era realmente lo que buscaba. Cuando ve 
el sistema en funcionamiento, descubre que realmente queria resolver era problema 
diferente. Si piensa que este tipo de evolution le va a ocurrir, entonces debe construir 
su primera version lo mas rapidamente posible para que pueda darse cuenta de si es 
eso lo que quiere. 

Quizas lo mas importante a recordar es que por defecto -por definition, realmente- 
si modifica una clase entonces su superclase -y subclases- seguiran funcionando. Ne- 
cesita perder el miedo a los cambios (especialmente si tiene un conjunto predefinido 
de pruebas unitarias para verificar la validez de sus cambios). La modification no 
rompera necesariamente el programa, y ningun cambio en el resultado estara limi- 
tado a las subclases y/o colaboradores especificos de la clase que cambie. 


1.9.7. Los planes valen la pena 

Por supuesto, no construiria una casa sin un monton de pianos cuidadosamen- 
te dibujados. Si construye un piso o una casa para el perro, sus pianos no seran 
muy elaborados pero probablemente empezara con algun tipo de esbozo para guiar- 
le en su camino. El desarrollo de software ha llegado a extremos. Durante mucho 
tiempo, la gente tenia poca estructura en sus desarrollos, pero entonces grandes pro- 
yectos empezaron a fracasar. Como resultado, se acabo utilizando metodologias que 
tenian una cantidad abrumadora de estructura y detalle, se intento principalmente 
para esos grandes proyectos. Estas metodologias eran muy complicadas de usar - 
la sensation era que se estaba perdiendo todo el tiempo escribiendo documentos y 
no programando (a menudo era asi). Espero haberle mostrado aqui sugerencias a 
medio camino - una escala proporcional. Usar una propuesta que se ajusta a sus ne- 
cesidades (y a su personalidad). No importa lo pequeno que desee hacerlo, cualquier 
tipo de plan supondra una gran mejora en su proyecto respecto a no planear nada. 
Recuerde que, segun la mayoria de las estimaciones, alrededor del 50 % de proyectos 
fracasan (jalgunas estimaciones superan el 70%!). 

Seguir un plan - preferiblemente uno simple y breve - y esbozar la estructura del 
diseno antes de empezar a codificar, descubrira que cosas caen juntas mas facilmen- 
te que si se lanza a programar, y tambien alcanzara un mayor grado de satisfaction. 
Mi experiencia me dice que llegar a una solution elegante es profundamente satis¬ 
factory en un nivel completamente diferente; parece mas arte que tecnologia. Y la 
elegancia siempre vale la pena; no es una busqueda frivola. No solo le permite te- 
ner un programa facil de construir y depurar, tambien es mas facil de comprender y 
mantener, y ahi es donde recae su valor economico. 


1.10. Programacion Extrema 

He estudiado tecnicas de analisis y diseno, por activa y por pasiva, desde mis 
estudios universitarios. El concepto de Programacion Extrema (XP) es el mas radi¬ 
cal y encantador que he visto nunca. Puede encontrar una cronica sobre el tema 
en Extreme Programming Explained de Kent Beck (Addison-Wesley 2000) y en la web 
www.xprogramming.com 

XP es una filosofia sobre el trabajo de programacion y tambien un conjunto de 
directrices para hacerlo. Alguna de estas directrices se reflejan en otras metodologias 
recientes, pero las dos contribuciones mas importantes y destacables, en mi opinion, 
son «escribir primero las pruebas» y la «programacion en parejas». Aunque defiende 
con fuerza el proceso completo, Benk senala que si adopta unicamente estas dos 
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practicas mejorara sensiblemente su productividad y fiabilidad. 


1.10.1. Escriba primero las pruebas 

El proceso de prueba se ha relegado tradicionalmente a la parte final del proyecto, 
despues de que «consiga tener todo funcionando, pero necesite estar seguro». Impli- 
citamente ha tenido una prioridad baja, y la gente que se especializa en ello nunca ha 
tenido estatus y suele trabajar en el sotano, lejos de los «programadores reales». Los 
equipos de pruebas han respondido al estereotipo, vistiendo trajes negros y hablan- 
do con regocijo siempre que encontraban algo (para ser honesto, yo tenia esa misma 
sensacion cuando encontraba falios en los compiladores de C++). 

XP revoluciona completamente el concepto del proceso de prueba dandole la 
misma (o incluso mayor) prioridad que al codigo. De hecho, se escriben las prue¬ 
bas antes de escribir el codigo que esta probando, y las pruebas permanecen con el 
codigo siempre. Las pruebas se deben ejecutar con exito cada vez que hace una inte- 
gracion del proyecto (algo que ocurre a menudo, a veces mas de una vez al dia). 

Escribir primero las pruebas tiene dos efectos extremadamente importantes. 

Primero, fuerza una definicion clara de la interfaz de la clase. A menudo sugiero 
que la gente «imagine la clase perfecta para resolver un problema particular co- 
mo una herramienta cuando intenta disenar el sistema. La estrategia del proceso de 
prueba de XP va mas lejos que eso - especifica exactamente cual es el aspecto de 
la clase, para el consumidor de esa clase, y exactamente como debe comportarse la 
clase. En ciertos terminos. Puede escribir toda la prosa, o crear todos los diagramas 
donde quiera describir como debe comportarse una clase y que aspecto debe tener, 
pero nada es tan real como un conjunto de pruebas. Lo primero es una lista de de- 
seos, pero las pruebas son un contrato forzado por el compilador y el programa. Es 
dificil imaginar una descripcion mas concreta de una clase que las pruebas. 

Mientras se crean las pruebas, el programador esta completamente forzado a ela- 
borar la clase y a menudo descubrira necesidades de funcionalidad que habrian sido 
omitidas durante los experimentos de diagramas UML, tarjetas CRC, casos de uso, 
etc. 

El segundo efecto importante de escribir las pruebas primero procede de la pro- 
pia ejecucion de las pruebas cada vez que hace una construccion del software. Esta 
actividad le ofrece la otra mitad del proceso de prueba que es efectuado por el compi¬ 
lador. Si mira la evolucion de los lenguajes de programacion desde esta perspectiva, 
vera que las mejoras reales en la tecnologia giran realmente alrededor del proceso 
de prueba. El lenguaje ensamblador solo se fija en la sintaxis, pero C impone algu- 
nas restricciones de semantica, y estas le impiden cometer ciertos tipos de errores. 
Los lenguajes POO imponen incluso mas restricciones semanticas, si lo piensa son 
realmente formas del proceso de prueba. «^Se utiliza apropiadamente este tipo de 
datos? ^Se invoca esta funcion del modo correcto?» son el tipo de pruebas que se 
llevan a cabo por el compilador en tiempo de ejecucion del sistema. Se han visto los 
resultados de tener estas pruebas incorporadas en el lenguaje: la gente ha sido capaz 
de escribir sistemas mas complejos, y han funcionado, con mucho menos tiempo y 
esfuerzo. He tratado de comprender porque ocurre eso, pero ahora me doy cuenta 
de que son las pruebas: el programador hace algo mal, y la red de seguridad de las 
pruebas incorporadas le dice que hay un problema y le indica donde. 

Pero las pruebas incorporadas que proporciona el diseno del lenguaje no pueden 
ir mas lejos. En este punto, el programador debe intervenir y anadir el resto de las 
pruebas que producen un juego completo (en cooperacion con el compilador y el 
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tiempo de ejecucion del sistema) que verifica el programa completo. Y, del mismo 
modo que tiene un compilador vigilando por encima de su hombro, querria que 
estas pruebas le ayudaran desde el principio? Por eso se escriben primero, y se ejecu- 
tan automaticamente con cada construccion del sistema. Sus pruebas se convierten 
en una extension de la red de seguridad proporcionada por el lenguaje. 

Una de las cosas que he descubierto sobre el uso de lenguajes de programacion 
cada vez mas poderosos es que estoy dispuesto a probar experimentos mas desca- 
rados, porque se que el lenguaje me ahorra la perdida de tiempo que supone estar 
persiguiendo errores. El esquema de pruebas de XP hace lo mismo para el proyecto 
completo. Como el programador conoce sus pruebas siempre cazara cualquier pro- 
blema que introduzca (y regularmente se anadiran nuevas pruebas), puede hacer 
grandes cambios cuando lo necesite sin preocuparse de causar un completo desas- 
tre. Eso es increiblemente poderoso. 


1.10.2. Programacion en parejas 

Programar en parejas va en contra del duro individualismo en el que hemos si- 
do adoctrinados desde el principio, a traves de la facultad (donde triunfabamos o 
fracasabamos por nosotros mismos, y trabajar con nuestros vecinos se consideraba 
«enganoso») y los medios de comunicacion, especialmente las peliculas de Holly¬ 
wood donde el heroe normalmente lucha contra la estupida conformidad 17 . Los 
programadores tambien se consideran dechados de individualismo -«cowboy co- 
ders» como le gusta decir a Larry Constantine. XP, que es en si mismo una batalla 
contra el pensamiento convencional, dice que el codigo deberia ser escrito por dos 
personas por estacion de trabajo. Y eso se puede hacer en una area con un grupo de 
estaciones de trabajo, sin las barreras a las que la gente de diseno de infraestructuras 
tiene tan to carino. De hecho. Beck dice que la primera tarea de pasarse a XP es llegar 
con destornilladores y llaves Allen y desmontar todas esas barreras 18 . (Esto reque- 
rira un director que pueda afrontar la ira del departamento de infraestructuras). 

El valor de la programacion en parejas esta en que mientras una persona escribe 
el codigo la otra esta pensando. El pensador mantiene un vision global en su cabeza, 
no solo la imagen del problema concreto, tambien las pautas de XP. Si dos personas 
estan trabajando, es menos probable que uno de ellos acabe diciendo, «No quiero 
escribir las pruebas primero», por ejemplo. Y si el programador se atasca, pueden 
cambiar los papeles. Si ambos se atascan, sus pensamientos pueden ser escuchados 
por otro en el area de trabajo que puede contribuir. Trabajar en parejas mantiene las 
cosas en movimiento y sobre la pista. Y probablemente mas importante, hace que la 
programacion sea mucho mas social y divertida. 

He empezado a usar programacion en parejas durante los periodos de ejercicio 
en algunos de mis seminarios y parece mejorar considerablemente la experiencia de 
todo el mundo. 


17 Aunque esto puede ser una perspectiva americana, las historias de Hollywood llegan a todas partes. 

18 Incluyendo (especialmente) el sistema PA. Una vez trabaje en una companla que insistia en anun- 
ciar publicamente cada llamada de telefono que llegaba a los ejecutivos, y constantemente interrumpla 
nuestra productividad (pero los directores no concebian el agobio como un servicio importante de PA). 
Finalmente, cuando nadie miraba empece a cortar los cables de los altavoces. 
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1.11. Porque triunfa C++ 

Parte de la razon por la que C++ ha tenido tanto exito es que la meta no era pre- 
cisamente convertir C en un lenguaje de POO (aunque comenzo de ese modo), sino 
tambien resolver muchos otros problemas orientados a los desarrolladores de hoy en 
dfa, especialmente aquellos que tienen grand es inversiones en C. Tradicionalmente, 
los lenguajes de POO han sufrido de la postura de que deberla abandonar todo lo 
que sabe y empezar desde cero, con un nuevo conjunto de conceptos y una nueva 
sintaxis, argumentando que es mejor a largo plazo todo el viejo equipaje que viene 
con los lenguajes procedurales. Puede ser cierto, a largo plazo. Pero a corto plazo, 
mucho de este equipaje era valioso. Los elementos mas valiosos podlan no estar en 
el codigo base existente (el cual, con las herramientas adecuadas, se podrla traducir), 
sino en el conocimiento adquirido. Si usted es un programador C y tiene que tirar todo 
lo que sabe sobre C para adoptar un nuevo lenguaje, inmediatamente sera mucho 
menos productivo durante muchos meses, hasta que su mente su ajuste al nuevo 
paradigma. Mientras que si puede apoyarse en su conocimiento actual de C y am- 
pliarlo, puede continuar siendo productivo con lo que realmente sabe mientras se 
pasa al mundo de la programacion orientada a objetos. Como todo el mundo tie¬ 
ne su propio modelo mental de la programacion, este cambio es lo suficientemente 
turbio sin el gasto anadido de volver a empezar con un nuevo modelo de lenguaje. 
Por eso, la razon del exito de C++, en dos palabras: es economico. Sigue costando 
cambiarse a la POO, pero con C++ puede costar menos 19 . 

La meta de C++ es mejorar la productividad. Esta viene por muchos caminos, 
pero el lenguaje esta disenado para ayudarle todo lo posible, y al mismo tiempo difi- 
cultarle lo menos posible con reglas arbitrarias o algun requisito que use un conjunto 
particular de caracterlsticas. C++ esta disenado para ser practico; las decisiones de 
diseno del lenguaje C++ estaban basadas en proveer los beneficios maximos al pro¬ 
gramador (por lo menos, desde la vision del mundo de C). 


1.11.1. Un C mejor 

Se obtiene una mejora incluso si continua escribiendo codigo C porque C++ ha 
cerrado muchos agujeros en el lenguaje C y ofrece mejor control de tipos y analisis 
en tiempo de compilacion. Esta obligado a declarar funciones de modo que el compi- 
lador pueda controlar su uso. La necesidad del preprocesador ha sido practicamente 
eliminada para sustitucion de valores y macros, que eliminan muchas dificultades 
para encontrar errores. C++ tiene una caracterlstica llamada referencias que permite 
un manejo mas conveniente de direcciones para argumentos de funciones y retorno 
de valores. El manejo de nombres se mejora a traves de una caracterlstica llamada 
sobrecarga de funciones, que le permite usar el mismo nombre para diferentes funcio¬ 
nes. Una caracterlstica llamada namespaces (espacios de nombres) tambien mejora la 
seguridad respecto a C. 


1.11.2. Usted ya esta en la curva de aprendizaje 

El problema con el aprendizaje de un nuevo lenguaje es la productividad. Ningu- 
na empresa puede permitirse de repente perder un ingeniero de software productivo 
porque esta aprendiendo un nuevo lenguaje. C++ es una extension de C, no una nue- 

19 Dije «puede» porque, debido a la complejidad de C++, realmente podrla ser mas economico cam¬ 
biarse a Java. Pero la decision de que lenguaje elegir tiene muchos factores, y en este libro asumire que el 
lector ha elegido C++. 
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va sintaxis completa y un modelo de programacion. Le permite continuar creando 
codigo util, usando las caracteristicas gradualmente segun las va aprendiendo y en- 
tendiendo. Puede que esta sea una de las razones mas importantes del exito de C++. 

Ademas, todo su codigo C es todavia viable en C++, pero como el compilador de 
C++ es mas delicado, a menudo encontrara errores ocultos de C cuando recompile 
su codigo con C++. 


1.11.3. Eficiencia 

A veces es apropiado intercambiar velocidad de ejecucion por productividad de 
programacion. Un modelo economico, por ejemplo, puede ser util solo por un pe- 
riodo corto de tiempo, pero es mas importante crear el modelo rapidamente. No 
obstante, la mayoria de las aplicaciones requieren a I gun grado de eficiencia, de mo- 
do que C++ siempre yerra en la parte de mayor eficiencia. Como los programadores 
de C tienden a ser muy concienzudos con la eficiencia, esta es tambien una forma de 
asegurar que no podran argumentar que el lenguaje es demasiado pesado y lento. 
Algunas caracteristicas en C++ intentan facilitar el afinado del rendimiento cuando 
el codigo generado no es lo suficientemente eficiente. 

No solo se puede conseguir el mismo bajo nivel de C (y la capacidad de escribir 
directamente lenguaje ensamblador dentro de un programa C++), ademas la expe- 
riencia practica sugiere que la velocidad para un programa C++ orientado a objetos 
tiende a ser ±10% de un programa escrito en C, y a menudo mucho menos 20 . El 
diseno producido por un programa POO puede ser realmente mas eficiente que el 
homologo en C. 


1.11.4. Los sistemas son mas faciles de expresar y entender 

Las clases disenadas para encajar en el problema tienden a expresarlo mejor. Esto 
significa que cuando escribe el codigo, esta describiendo su solucion en los terminos 
del espacio del problema («ponga el FIXME:plastico en el cubo») mejor que en los 
terminos de la computadora, que estan en el espacio de la solucion («active el bit 
para cerrar el rele »). Usted maneja conceptos de alto nivel y puede hacer mucho 
mas con una linica linea de codigo. 

El otro beneficio de esta facilidad de expresion es el mantenimiento, que (si in¬ 
forma se puede creer) implica una enorme parte del coste del tiempo de vida del 
programa. Si un programa es mas facil de entender, entonces es mas facil de mante- 
ner. Tambien puede reducir el coste de crear y mantener la documentacion. 


1.11.5. Aprovechamiento maximo con librerias 

El camino mas rapido para crear un programa es usar codigo que ya esta escri¬ 
to: una libreria. Un objetivo primordial de C++ es hacer mas sencillo el uso de las 
librerias. Esto se consigue viendo las librerias como nuevos tipos de datos (clases), 
asi que crear librerias significa anadir nuevos tipos al lenguaje. Como el compilador 
C++ se preocupa del modo en que se usa la libreria - garantizando una inicializacion 
y limpieza apropiadas, y asegurando que las funciones se llamen apropiadamente - 
puede centrarse en lo que hace la libreria, no en como tiene que hacer lo. 


20 Sin embargo, mire en las columnas de Dan Saks en C/C++ User's Journal sobre algunas investigacio- 
nes importantes sobre el rendimiento de librerias C++. 
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Como los nombres estan jerarquizados segun las partes de su programa por me¬ 
dio de los espacios de nombres de C++, puede usar tantas librerlas como quiera sin 
los conflictos de nombres tipicos de C. 


1.11.6. Reutilizacion de codigo fuente con plantillas 

Hay una categorla significativa de tipos que requiere modificaciones del codi¬ 
go fuente para lograr una reutilizacion efectiva. Las plantillas de C++ llevan a cabo 
la modification del codigo fuente automaticamente, convirtiendola en una herra- 
mienta especialmente potente para la reutilizacion del codigo de las librerlas. Si se 
disena un tipo usando plantillas funcionara facilmente con muchos otros tipos. Las 
plantillas son especialmente interesantes porque ocultan al programador cliente la 
complejidad de esta forma de reutilizar codigo. 


1.11.7. Manejo de errores 

La gestion de errores en C es un problema muy conocido, y a menudo ignorado 
- cruzando los dedos. Si esta construyendo un programa complejo y grande, no hay 
nada peor que tener un error enterrado en cualquier lugar sin la menor idea de como 
llego alll. La gestion de excepciones de C++ (introducida en este volumen, y expli- 
cada en detalle en el Volumen 2, que se puede descargar de www.BruceEckel.com) 
es un camino para garantizar que se notifica un error y que ocurre algo como conse- 
cuencia. 


1.11.8. Programar a lo grande 

Muchos lenguajes tradicionales tienen limitaciones propias para hacer progra- 
mas grandes y complejos. BASIC, por ejemplo, puede valer para solucionar ciertas 
clases de problemas rapidamente, pero si el programa tiene mas de unas cuantas 
paginas o se sale del dominio de problemas de ese lenguaje, es como intentar nadar 
a traves de un fluido cada vez mas viscoso. C tambien tiene estas limitaciones. Por 
ejemplo, cuando un programa tiene mas de 50.000 lrneas de codigo, los conflictos 
de nombres empiezan a ser un problema - efectivamente, se queda sin nombres de 
funciones o variables. Otro problema particularmente malo son los pequenos agu- 
jeros en el lenguaje C - errores enterrados en un programa grande que pueden ser 
extremadamente dificiles de encontrar. 

No hay una linea clara que diga cuando un lenguaje esta fallando, y si la hubiese, 
deberia ignorarla. No diga: «Mi programa BASIC se ha hecho demasiado grande; jlo 
tendre que reescribir en C!» En su lugar, intente calzar unas cuantas lineas mas para 
anadirle una nueva caracteristica. De ese modo, el coste extra lo decide usted. 

C++ esta disenado para ayudarle a programar a lo grande, es decir, eliminar las 
diferencias de complejidad entre un programa pequeno y uno grande. Ciertamente 
no necesita usar POO, plantillas, espacios de nombres ni manejadores de excepciones 
cuando este escribiendo un programa tipo «hola mundo», pero estas prestaciones 
estan ahi para cuando las necesite. Y el compilador es agresivo en la detection de 
errores tanto para programas pequenos como grandes. 
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1.12. Estrategias de transicion 

Si acepta la POO, su proxima pregunta seguramente sera: «^como puedo hacer 
que mi jefe, mis colegas, mi departamento, mis companeros empiecen a utilizar ob- 
jetos?» Piense sobre como usted -un programador independiente- puede ir apren- 
diendo a usar un nuevo lenguaje y un nuevo paradigma de programacion. Ya lo ha 
hecho antes. Primero viene la educacion y los ejemplos; entonces llega un proyecto 
de prueba que le permita manejar los conceptos basicos sin que se vuelva demasiado 
confuso. Despues llega un proyecto del «mundo real» que realmente hace algo util. 
Durante todos sus primeros proyectos continua su educacion leyendo, preguntan- 
do a expertos, e intercambiando consejos con amigos. Este es el acercamiento que 
sugieren muchos programadores experimentados para el cambio de C a C++. Por 
supuesto, cambiar una compania entera introduce ciertas dinamicas de grupo, pero 
puede ayudar en cada paso recordar como lo haria una persona. 


1.12.1. Directrices 

Aqui hay algunas pautas a considerar cuando se hace la transicion a POO y C++: 

Entrenamiento 

El primer paso es algun tipo de estudio. Recuerde la inversion que la compania 
tiene en codigo C, e intente no tenerlo todo desorganizado durante seis o nueve me- 
ses mientras todo el mundo alucina con la herencia multiple. Elija un pequeno grupo 
para formarlo, preferiblemente uno compuesto de gente que sea curiosa, trabaje bien 
junta, y pueda funcionar como su propia red de soporte mientras estan aprendiendo 
C++. 

Un enfoque alternative que se sugiere a veces es la ensenanza a todos los niveles 
de la compania a la vez, incluir una vision general de los cursos para gerentes es- 
trategicos es tan bueno como cursos de diseno y programacion para trabajadores de 
proyectos. Es especialmente bueno para companias mas pequenas al hacer cambios 
fundamentals en la forma en la que se hacen cosas, o en la division de niveles en 
companias mas grandes. Como el coste es mayor, sin embargo, se puede cambiar 
algo al empezar con entrenamiento de nivel de proyecto, hacer un proyecto piloto 
(posiblemente con un mentor externo), y dejar que el equipo de trabajo se convierta 
en los profesores del resto de la compania. 

Proyectos de bajo riesgo 

Pruebe primero con un proyecto de bajo riesgo que permita errores. Una vez que 
adquiera alguna experiencia, puede acometer cualquier otro proyecto con miembros 
del primer equipo o usar los miembros del equipo como una plantilla de soporte 
tecnico de POO. Este primer proyecto puede que no funcione bien la primera vez, 
pero no deberia ser una tarea critica para la compania. Deberia ser simple, auto- 
contenido, e instructivo; eso significa que suele implicar la creacion de clases que 
seran significativas para otros programadores en la compania cuando les llegue el 
turno de aprender C++. 

Modelar desde el exito 

Buscar ejemplos de un buen diseno orientado a objetos antes de partir de cero. 
Hay una gran probabilidad de que alguien ya haya resuelto su problema, y si ellos no 
lo han resuelto probablemente puede aplicar lo que ha aprendido sobre abstraccion 
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para modificar un diseno existente y adecuarlo a sus necesidades. Este es el concepto 
general de los patrones de diseno, tratado en el Volumen 2. 

Use librerfas de clases existentes 

La primera motivacion economica para cambiar a POO es el facil uso de codi- 
go existente en forma de librerfas de clases (en particular, las librerfas Estandar de 
C++, explicadas en profundidad en el Volumen 2 de este libro). El ciclo de desarrollo 
de aplicacion mas corto ocurrira cuando solo tenga que escribir la funcion main (), 
creando y usando objetos de las librerfas de fabrica. No obstante, algunos progra- 
madores nuevos no lo entienden, no son conscientes de la existencia de librerfas de 
clases, o, a traves de la fascinacion con el lenguaje, desean escribir clases que ya exis- 
ten. Su exito con POO y C++ se optimizara si hace un esfuerzo por buscar y reutilizar 
codigo de otras personas desde el principio del proceso de transition. 

No reescriba en C++ codigo que ya existe 

Aunque compilar su codigo C con un compilador de C++ normalmente produce 
(de vez en cuando tremendos) beneficios encontrando problemas en el viejo codigo, 
normalmente coger codigo funcional existente y reescribirlo en C++ no es la mejor 
manera de aprovechar su tiempo. (Si tiene que convertirlo en objetos, puede «envol- 
ver» el codigo C en clases C++). Hay beneficios incrementales, especialmente si es 
importante reutilizar el codigo. Pero esos cambios no le van a mostrar los espectacu- 
lares incrementos en productividad que espera para sus primeros proyectos a menos 
que ese proyecto sea nuevo. C++ y la POO destacan mas cuando un proyecto pasa 
del concepto a la realidad. 


1.12.2. Obstaculos de la gestion 

Si es gerente, su trabajo es adquirir recursos para su equipo, para superar las ba- 
rreras en el camino del exito de su equipo, y en general para intentar proporcionar el 
entorno mas productivo y agradable de modo que sea mas probable que su equipo 
realice esos milagros que se le piden siempre. Cambiar a C++ cae en tres de estas ca- 
tegorfas, y puede ser maravilloso si no le costara nada. Aunque cambiar a C++ puede 
ser mas economico - dependiendo de sus restricciones 21 - como las alternativas de la 
POO para un equipo de programadores de C (y probablemente para programadores 
en otros lenguajes procedurales), no es gratis, y hay obstaculos que deberfa conocer 
antes de intentar comunicar el cambio a C++ dentro de su companfa y embarcarse 
en el cambio usted mismo. 

Costes iniciales 

El coste del cambio a C++ es mas que solamente la adquisicion de compiladores 
C++ (el compilador GNU de C++, uno de los mejores, es libre y gratuito). Sus costes 
a medio y largo plazo se minimizaran si invierte en formation (y posiblemente un 
mentor para su primer proyecto) y tambien si identifica y compra librerfas de cla¬ 
ses que resuelvan su problema mas que intentar construir las librerfas usted mismo. 
Hay costes que se deben proponer en un proyecto realista. Ademas, estan los costes 
ocultos en perdidas de productividad mientras se aprende el nuevo lenguaje y po¬ 
siblemente un nuevo entorno de programacion. Formar y orientar puede minimizar 
ese efecto, pero los miembros del equipo deben superar sus propios problemas pa- 


21 Para mejora de la productividad, deberia considerar tambien el lenguaje Java. 
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ra entender la nueva tecnologla. A lo largo del proceso ellos cometer an mas errores 
(esto es una ventaja, porque los errores reconocidos son el modo mas rapido para 
aprender) y ser menos productivos. Incluso entonces, con algunos tipos de proble- 
mas de programacion, las clases correctas y el entorno de programacion adecuado, 
es posible ser mas productivo mientras se esta aprendiendo C++ (incluso conside- 
rando que esta cometiendo mas errores y escribiendo menos lrneas de codigo por 
dia) que si estuviera usando C. 

Cuestiones de rendimiento 

Una pregunta comun es, «^La POO no hace automaticamente mis programas 
mucho mas grandes y lentos?» La respuesta es: «depende». Los lenguajes de POO 
mas tradicionales se disenaron con experimentacion y prototipado rapido mas que 
pensando en la eficiencia. De esta manera, practicamente garantiza un incremento 
significativo en tamano y una disminucion en velocidad. C++ sin ambargo, esta di- 
senado teniendo presente la produccion de programacion. Cuando su objetivo es 
un prototipado rapido, puede lanzar componentes juntos tan rapido como sea po¬ 
sible ignorando las cuestiones de eficiencia. Si esta usando una librerias de otros, 
normalmente ya estan optimizadas por sus vendedores; en cualquier caso no es un 
problema mientras esta en un modo de desarrollo rapido. Cuando tenga el sistema 
que quiere, si es bastante pequeno y rapido, entonces ya esta hecho. Si no, lo puede 
afinar con una herramienta de perfilado, mire primero las mejoras que puede con- 
seguir aplicando las caracterlsticas que incorpora C++. Si esto no le ayuda, mire las 
modificaciones que se pueden hacer en la implementacion subyacente de modo que 
no sea necesario cambiar ningun codigo que utilice una clase particular. Unicamente 
si ninguna otra cosa soluciona el problema necesitara cambiar el diseno. El hecho de 
que el rendimiento sea tan critico en esta fase del diseno es un indicador de que debe 
ser parte del criterio del diseno principal. FIXME:Usar un desarrollo rapido tiene la 
ventaja de darse cuenta rapidamente. 

Como se menciono anteriormente, el numero dado con mas frecuencia para la 
diferencia en tamano y velocidad entre C y C++ es 10%, y a menudo menor. Incluso 
podria conseguir una mejora significativa en tamano y velocidad cuando usa C++ 
mas que con C porque el diseno que hace para C++ puede ser bastante diferente 
respecto al que hizo para C. 

La evidencia entre las comparaciones de tamano y velocidad entre C y C++ tien- 
den a ser anecdoticas y es probable que permanezcan asi. A pesar de la cantidad de 
personas que sugiere que una compama intenta el mismo proyecto usando C y C++, 
probablemente ninguna compama quiere perder dinero en el camino a no ser que sea 
muy grande y este interesada en tales proyectos de investigacion. Incluso entonces, 
parece que el dinero se puede gastar mejor. Casi universalmente, los programadores 
que se han cambiado de C (o cualquier otro lenguaje procedural) a C++ (o cualquier 
otro lenguaje de POO) han tenido la experiencia personal de una gran mejora en 
su productividad de programacion, y es el argumento mas convincente que pueda 
encontrar. 

Errores comunes de diseno 

Cuando su equipo empieza con la POO y C++, tlpicamente los programadores 
pasan por una serie de errores de diseno comunes. Esto ocurre a menudo porque 
hay poca realimentacion de expertos durante el diseno e implementacion de los pro¬ 
yectos iniciales, porque ningun experto ha sido desarrollador dentro de la compama 
y puede haber resistencia a contratar consultores. Es facil pensar que se entiende la 
POO demasiado pronto en el ciclo y se va por el mal camino. Algo que es obvio para 
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alguien experimentado con el lenguaje puede ser un tema de gran debate interno 
para un novato. La mayor parte de este trauma se puede olvidar usando un experto 
externo para ensenar y tutorizar. 

Por otro lado, el hecho de que estos errores de diseno son faciles de cometer, 
apunta al principal inconveniente de C++: su compatibilidad con C (por supuesto, 
tambien es su principal fortaleza). Para llevar a cabo la hazana de ser capaz de com- 
pilar codigo C, el lenguaje debe cumplir algunos compromisos, lo que ha dado lugar 
a algunos «rincones oscuros». Esto es una realidad, y comprende gran parte de la 
curva de aprendizaje del lenguaje. En este libro y en el volumen posterior (y en otros 
libros; ver el Apendice C), intento mostrar la mayoria de los obstaculos que proba- 
blemente encontrara cuando trabaje con C++. Deberia ser consciente siempre de que 
hay algunos agujeros en la red de seguridad. 


1.13. Resumen 

Este capitulo intenta darle sentido a los extensos usos de la programacion orien- 
tada a objetos y C++, incluyendo el porque de que la POO sea diferente, y porque 
C++ en particular es diferente, conceptos de metodologia de POO, y finalmente los 
tipos de cuestiones que encontrara cuando cambie su propia compahia a POO y C++. 

La POO y C++ pueden no ser para todos. Es importante evaluar sus necesidades 
y decidir si C++ satisfara de forma optima sus necesidades, o si podria ser mejor con 
otros sistemas de programacion (incluido el que utiliza actualmente). Si sabe que sus 
necesidades seran muy especializadas en un futuro inmediato y tiene restricciones 
especificas que no se pueden satisfacer con C++, entonces debe investigar otras alter- 
nativas 22 . Incluso si finalmente elige C++ como su lenguaje, por lo menos entendera 
que opciones habia y tendra una vision clara de porque tomo esa direccion. 

El lector conoce el aspecto de un programa procedural: definiciones de datos y 
llamadas a funciones. Para encontrar el significado de un programa tiene que tra- 
bajar un poco, revisando las llamadas a funcion y los conceptos de bajo nivel para 
crear un modelo en su mente. Esta es la razon por la que necesitamos representacio- 
nes intermedias cuando disenamos programas procedurales - por eso mismo, estos 
programas tienden a ser confusos porque los terminos de expresion estan orientados 
mas hacia la computadora que a resolver el problema. 

Como C++ anade muchos conceptos nuevos al lenguaje C, puede que su asun- 
cion natural sea que el main () en un programa de C++ sera mucho mas complicado 
que el equivalente del programa en C. En eso, quedara gratamente sorprendido: un 
programa C++ bien escrito es generalmente mucho mas simple y mucho mas senci- 
llo de entender que el programa equivalente en C. Lo que vera son las definiciones 
de los objetos que representan conceptos en el espacio de su problema (en lugar de 
cuestiones de la representacion en el computador) y mensajes enviados a otros ob¬ 
jetos para representar las actividades en este espacio. Ese es uno de los placeres de 
la programacion orientada a objetos, con un programa bien disenado, es facil enten¬ 
der el codigo leyendolo. Normalmente hay mucho menos codigo, en parte, porque 
muchos de sus problemas se resolveran utilizando codigo de librerias existentes. 


22 En particular, recomiendo mirar Java http: / /java.sun.com y Python http: / /www.python.org. 
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2: Construir y usar objetos 

Este capitulo presenta la suficiente sintaxis y los conceptos de 
construction de programas de C++ como para permitirle crear y eje- 
cutar algunos programas simples orientados a objetos. El siguiente 
capftulo cubre la sintaxis basica de C y C++ en detalle. 

Leyendo primero este capitulo, le cogera el gustillo a lo que supone programar 
con objetos en C++, y tambien descubrira algunas de las razones por las que hay 
tanto entusiasmo alrededor de este lenguaje. Deberla ser suficiente para pasar al 
Capitulo 3, que puede ser un poco agotador debido a que contiene la mayoria de los 
detalles del lenguaje C. 

Los tipos de datos definidos por el usuario, o clases es lo que diferencia a C++ 
de los lenguajes procedimentales tradicionales. Una clase es un nuevo tipo de datos 
que usted o alguna otra persona crea para resolver un problema particular. Una vez 
que se ha creado una clase, cualquiera puede utilizarla sin conocer los detalles de su 
funcionamiento, o incluso de la forma en que se han construido. Este capitulo trata 
las clases como si solo fueran otro tipo de datos predefinido disponible para su uso 
en programas. 

Las clases creadas por terceras personas se suelen empaquetar en librerias. Este 
capitulo usa algunas de las librerias que vienen en todas las implementaciones de 
C++. Una libreria especialmente importante es FIXME:iostreams, que le permite (en- 
tre otras cosas) leer desde ficheros o teclado, y escribir a ficheros o pantalla. Tambien 
vera la clase string, que es muy practica, y el contenedor vector de la Libreria Es- 
tandar de C++. Al final del capitulo, vera lo sencillo que resulta utilizar una libreria 
de clases predefinida. 

Para que pueda crear su primer programa debe conocer primero las herramientas 
utilizadas para construir aplicaciones. 


2.1. El proceso de traduccion del lenguaje 

Todos los lenguajes de programacion se traducen de algo que suele ser facilmente 
entendible por una persona (codigo fuente) a algo que es ejecutado por una compu- 
tadora (codigo mdquind). Los traductores se dividen tradicionalmente en dos catego- 
rias: interpretes y compiladores. 


2.1.1. Interpretes 

Un interprete traduce el codigo fuente en actividades (las cuales pueden com- 
prender grupos de instrucciones maquina) y ejecuta inmediatamente estas activida- 
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des. El BASIC, por ejemplo, fue un lenguaje interpretado bastante popular. Los in¬ 
terpretes de BASIC tradicionales traducen y ejecutan una linea cada vez, y despues 
olvidan la linea traducida. Esto los hace lentos debido a que deben volver a tradu- 
cir cualquier codigo que se repita. BASIC tambien ha sido compilado para ganar en 
velocidad. La mayoria de los interpretes modernos, como los de Python, traducen 
el programa entero en un lenguaje intermedio que es ejecutable por un interprete 
mucho mas rapido 1 . 

Los interpretes tienen muchas ventajas. La transicion del codigo escrito al codigo 
ejecutable es casi inmediata, y el codigo fuente esta siempre disponible, por lo que 
el interprete puede ser mucho mas espedfico cuando ocurre un error. Los beneficios 
que se suelen mencionar de los interpretes es la facilidad de interaction y el rapido 
desarrollo (pero no necesariamente ejecucion) de los programas. 

Los lenguajes interpretados a menudo tienen severas limitaciones cuando se cons- 
truyen grandes proyectos (Python parece ser una exception). El interprete (o una 
version reducida) debe estar siempre en memoria para ejecutar el codigo e incluso el 
interprete mas rapido puede introducir restricciones de velocidad inaceptables. La 
mayoria de los interpretes requieren que todo el codigo fuente se les envie de una 
sola vez. Esto no solo introduce limitaciones de espacio, sino que puede causar erro- 
res dificiles de detectar si el lenguaje no incluye facilidades para localizar el efecto 
de las diferentes porciones de codigo. 


2.1.2. Compiladores 

Un compilador traduce el codigo fuente directamente a lenguaje ensamblador o 
instrucciones maquina. El producto final suele ser uno o varios ficheros que contie- 
nen codigo maquina. La forma de realizarlo suele ser un proceso que consta de varios 
pasos. La transicion del codigo escrito al codigo ejecutable es significativamente mas 
larga con un compilador. 

Dependiendo de la perspicacia del escritor del compilador, los programas gene- 
rados por un compilador tienden a requerir mucho menos espacio para ser ejecuta- 
dos, y se ejecutan mucho mas rapido. Aunque el tamano y la velocidad son proba- 
blemente las razones mas citadas para usar un compilador, en muchas situaciones 
no son las mas importantes. Algunos lenguajes (como el C) estan disenados para 
admitir trozos de programas compilados independientemente. Estas partes termi- 
nan combinando en un programa ejecutable final mediante una herramienta llamada 
enlazador (linker). Este proceso se conoce como compilacion sepamda. 

La compilacion separada tiene muchos beneficios. Un programa que, tornado de 
una vez, excederia los limites del compilador o del entorno de compilacion puede ser 
compilado por piezas. Los programas se pueden ser construir y probar pieza a pieza. 
Una vez que una parte funciona, se puede guardar y tratarse como un bloque. Los 
conjuntos de piezas ya funcionales y probadas se pueden combinar en librerias para 
que otros programadores puedan usarlos. Como se crean piezas, la complejidad de 
las otras piezas se mantiene oculta. Todas estas caracteristicas ayudan a la creation 
de programas grandes, 2 . 

Las caracteristicas de depuration del compilador han mejorado considerable- 


1 Los li'mites entre los compiladores y los interpretes tienden a ser difusos, especialmente con Python, 
que tiene muchas de las caracteristicas y el poder de un lenguaje compilado pero tambien tiene parte de 
las ventajas de los lenguajes interpretados. 

2 Python vuelve a ser una excepcion, debido a que permite compilacion separada. 
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mente con el tiempo. Los primeros compiladores simplemente generaban codigo 
maquina, y el programador insertaba sentencias de impresion para ver que esta- 
ba ocurriendo, lo que no siempre era efectivo. Los compiladores modernos pueden 
insertar informacion sobre el codigo fuente en el programa ejecutable. Esta informa- 
cion se usa por poderosos depuradores a nivel de codigo que muestran exactamente lo 
que pasa en un programa rastreando su progreso mediante su codigo fuente. 

Algunos compiladores solucionan el problema de la velocidad de compilacion 
mediante compilacion en memoria. La mayoria de los compiladores trabajan con fi- 
cheros, leyendolos y escribiendolos en cada paso de los procesos de compilacion. 
En la compilacion en memoria el compilador se mantiene en RAM. Para programas 
pequenos, puede parecerse a un interprete. 


2.1.3. El proceso de compilacion 

Para programar en C y en C++, es necesario entender los pasos y las herramientas 
del proceso de compilacion. Algunos lenguajes (C y C++, en particular) empiezan la 
compilacion ejecutando un preprocesador sobre el codigo fuente. El preprocesador es 
un programa simple que sustituye patrones que se encuentran en el codigo fuente 
con otros que ha definido el programador (usando las directions de preprocesado). Las 
directivas de preprocesado se utilizan para ahorrar escritura y para aumentar la legi- 
libilidad del codigo (posteriormente en este libro, aprendera como el diseno de C++ 
desaconseja en gran medida el uso del preprocesador, ya que puede causar errores 
sutiles). El codigo preprocesado se suele escribir en un fichero intermedio. 

Normalmente, los compiladores hacen su trabajo en dos pasadas. La primera pa- 
sada consiste en analizar sintacticamente el codigo generado por el preprocesador. 
El compilador trocea el codigo fuente en pequenas partes y lo organiza en una es- 
tructura llamada drbol. En la expresion FIXME:«A+B», los elementos «A», «+», «B» 
son hojas del arbol. 

A menudo se utiliza un optimizador global entre el primer y el segundo paso para 
producir codigo mas pequeno y rapido. 

En la segunda pasada, el generador de codigo recorre el arbol sintactico y genera 
lenguaje ensamblador o codigo maquina para los nodos del arbol. Si el generador 
de codigo crea lenguaje ensamblador, entonces se debe ejecutar el programa ensam¬ 
blador. El resultado final en ambos casos es un modulo objeto (un fichero que tipica- 
mente tiene una extension de . o o . ob j. A veces se utiliza un optimizador de mirilla 
en esta segunda pasada para buscar trozos de codigo que contengan sentencias re- 
dundantes de lenguaje ensamblador. 

Usar la palabra «objeto» para describir pedazos de codigo maquina es un hecho 
desafortunado. La palabra comenzo a usarse antes de que la programacion orien- 
tada a objetos tuviera un uso generalizado. «Objeto» significa lo mismo que «FIX- 
ME:meta» en este contexto, mientras que en la programacion orientada a objetos 
significa «una cosa con limites». 

El enlazador combina una lista de modulos objeto en un programa ejecutable que 
el sistema operativo puede cargar y ejecutar. Cuando una funcion en un modulo ob¬ 
jeto hace una referencia a una funcion o variable en otro modulo objeto, el enlazador 
resuelve estas referencias; se asegura de que todas las funciones y los datos externos 
solicitados durante el proceso de compilacion existen realmente. Ademas, el enlaza¬ 
dor anade un modulo objeto especial para realizar las actividades de inicializacion. 

El enlazador puede buscar en unos archivos especiales llamados librerias para 
resolver todas sus referencias. Una libreria contiene una coleccion de modulos objeto 
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en un unico fichero. Una libreria se crea y mantiene por un programa conocido como 
bibliotecario ( librarian ). 

Comprobacion estatica de tipos 

El compilador realiza una comprobacion de tipos durante la primera pasada. La 
comprobacion de tipos asegura el correcto uso de los argumentos en las funciones 
y previene muchos tipos de errores de programacion. Como esta comprobacion de 
tipos ocurre se hace la compilacion y no cuando el programa se esta ejecutado, se 
conoce como comprobacion estatica de tipos. 

Algunos lenguajes orientados a objetos (Java por ejemplo) realizan comproba- 
ciones en tiempo de ejecucion ( comprobacion dindmica de tipos). Si se combina con la 
estatica, la comprobacion dinamica es mas potente que solo la estatica. Sin embargo, 
anade una sobrecarga a la ejecucion del programa. 

C++ usa la comprobacion estatica de tipos debido a que el lenguaje no puede 
asumir ningun soporte particular durante la ejecucion. La comprobacion estatica de 
tipos notifica al programador malos usos de los tipos durante la compilacion, y as! 
maximiza la velocidad de ejecucion. A medida que aprenda C++, comprobara que la 
mayoria de las decisiones de diseno del lenguaje estan tomadas en favor de la mejora 
del rendimiento, motivo por el cual C es famoso en la programacion orientada a la 
production. 

Se puede deshabilitar la comprobacion estatica de tipos en C++, e incluso per- 
mite al programador usar su propia comprobacion dinamica de tipos - simplemente 
necesita escribir el codigo. 


2.2. Herramientas para compilacion modular 

La compilacion modular es particularmente importante cuando se construyen 
grandes proyectos. En C y en C++, un programa se puede crear en pequenas piezas, 
manejables y comprobables de forma independiente. La herramienta mas impor¬ 
tante para dividir un programa en piezas mas pequenas es la capacidad de crear 
subrutinas o subprogramas que tengan un nombre que las identifique. En C y en 
C++, estos subprogramas se llamana funciones, que son las piezas de codigo que se 
pueden almacenar en diferentes ficheros, permitiendo la compilacion separada. Di- 
cho de otra forma, una funcion es la unidad atomica de codigo, debido a que no se 
puede tener una parte de una funcion en un fichero y el resto en otro (aunque los 
ficheros pueden contener mas de una funcion). 

Cuando se invoca una funcion, se le suelen pasar una serie de argumentos , que 
son valores que desea que la funcion utilice durante su ejecucion. Cuando la fun¬ 
cion termina, normalmente devuelve un valor de retorno , que equivale al resultado. 
Tambien es posible crear funciones que no tengan ni argumentos ni valor de retorno. 

Para crear un programa con multiples ficheros, las funciones de un fichero deben 
acceder a las funciones y los datos de otros ficheros. Cuando se compila un fichero, el 
compilador de C o C++ debe conocer las funciones y los datos de los otros ficheros, 
en particular sus nombres y su uso apropiado. El compilador asegura que las fun¬ 
ciones y los datos son usados correctamente. El proceso de "decirle al compilador" 
los nombres de las funciones externas y los datos que necesitan es conocido como 
declaration. Una vez declarada una funcion o una variable, el compilador sabe como 
comprobar que la funcion se utiliza adecuadamente. 
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2.2.1. Declaraciones vs definiciones 

Es importante comprender la diferencia entre declaraciones y definiciones porque 
estos terminos se usaran de forma precisa en todo el libro. Basicamente todos los 
programas escritos en C o en C++ requieren declaraciones. Antes de poder escribir 
su primer programa, necesita comprender la manera correcta de escribir una decla¬ 
ration. 

Una declaration presenta un nombre -identificador- al compilador. Le dice al com- 
pilador «Esta funcion o esta variable existe en algun lugar, y este es el aspecto que 
debe tener». Una definition, sin embargo, dice: «Crea esta variable aqui» o «Crea esta 
funcion aqui». Eso reserva memoria para el nombre. Este significado sirve tanto para 
una variable que para una funcion; en ambos casos, el compilador reserva espacio 
en el momento de la definicion. Para una variable, el compilador determina su ta- 
mano y reserva el espacio en memoria para contener los datos de la variable. Para 
una funcion, el compilador genera el codigo que finalmente ocupara un espacio en 
memoria. 

Se puede declarar una variable o una funcion en muchos sitios diferentes, pero en 
C o en C++ solo se puede definir una vez (se conoce a veces como Regia de Definicion 
Unica (ODR) 3 ). Cuando el enlazador une todos los modulos objeto, normalmente se 
quejara si encuentra mas de una definicion para la misma funcion o variable. 

Una definicion puede ser tambien una declaracion. Si el compilador no ha visto 
antes el nombre x y hay una definicion int x; , el compilador ve el nombre tambien 
como una declaracion y asigna memoria al mismo tiempo. 

Sintaxis de declaracion de funciones 

La declaracion de una funcion en C y en C++ consiste en escribir el nombre de la 
funcion, los tipos de argumentos que se pasan a la funcion, y el valor de retorno de 
la misma. Por ejemplo, aqui tenemos la declaracion de una funcion llamada func- 
1 () que toma dos enteros como argumentos (en C/C++ los enteros se denotan con 
la palabra reservada int) y que devuelve un entero: 

int fund (int, int); 

La primera palabra reservada es el valor de retorno: int. Los argumentos estan 
encerrados entre parentesis despues del nombre de la funcion en el orden en que 
se utilizan. El punto y coma indica el final de la sentencia; en este caso le dice al 
compilador «esto es todo - jaqui no esta la definicion de la funcion!». 

Las declaraciones en C y C++ tratan de mimetizar la forma en que se utilizara ese 
elemento. Por ejemplo, si a es otro entero la funcion de arriba se deberia usar de la 
siguiente manera: 

a = fund (2, 3) ; 


Como fund () devuelve un entero, el compilador de C/C++ comprobara el 
uso de fund () para asegurarse que a puede aceptar el valor devuelto y que los 
argumentos son validos. 

Los argumentos de las declaraciones de funciones pueden tener nombres. El com¬ 
pilador los ignora pero pueden ser utilies como nemotecnicos para el usuario. Por 

3 One Definition Rule 
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ejemplo, se puede declarar fund () con una apariencia diferente pero con el mismo 
significado: 

j int funcl(int length, int width); 



Una puntualizacion 

Existe una diferencia significativa entre C y el C++ para las funciones con lista de 
argumentos vacia. En C, la declaracion: 

int func2 () ; 

significa «una funcion con cualquier numero y tipo de argumentos», lo cual anula 
la comprobacion de tipos. En C++, sin embargo, significa «una funcion sin argumen- 
tos». 

Definicion de funciones 

La definicion de funciones se parece a la declaracion excepto en que tienen cuer- 
po. Un cuerpo es un conjunto de sentencias encerradas entre llaves. Las llaves in¬ 
dican el comienzo y el final del codigo. Para dar a fund () una definicion con un 
cuerpo vacio (un cuerpo que no contiene codigo), escriba: 

int fund (int ancho, int largo) {} 

Note que en la definicion de la funcion las llaves sustituyen el punto y coma. 
Como las llaves contienen una sentencia o grupo de sentencias, no es necesario un 
punto y coma. Tenga en cuenta ademas que los argumentos en la definicion de la 
funcion deben nombres si los quiere usar en el cuerpo de la funcion (como aqui no 
se usan, son opcionales). 

Sintaxis de declaracion de variables 

El significado atribuido a la frase «declaracion de variables» historicamente ha 
sido confuso y contradictorio, y es importante que entienda el significado correcto 
para poder leer el codigo correctamente. Una declaracion de variable dice al com- 
pilador como es la variable. Dice al compilador, «Se que no has visto este nombre 
antes, pero te prometo que existe en algun lugar, y que es una variable de tipo X». 

En una declaracion de funcion, se da un tipo (el valor de retorno), el nombre 
de la funcion, la lista de argumentos, y un punto y coma. Con esto el compilador 
ya tiene suficiente informacion para saber como sera la funcion. Por inferencia, una 
declaracion de variable consistira en un tipo seguido por un nombre. Por ejemplo: 

int a; 

podria declarar la variable a como un entero usando la logica usada anterior- 
mente. Pero aqui esta el conflicto: existe suficiente informacion en el codigo anterior 
como para que el compilador pueda crear espacio para un entero llamado a y es 
exactamente lo que ocurre. Para resolver el dilema, fue necesaria una palabra re- 
servada en C y C++ para decir «Esto es solo una declaracion; esta variable estara 
definida en algun otro lado». La palabra reservada es extern que puede significar 
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que la definicion es externa al fichero, o que la definicion se encuentra despues en 
este fichero. 

Declarar una variable sin definirla implica usar la palabra reservada extern an¬ 
tes de una description de la variable, como por ejemplo: 

extern int a; 

extern tambien se puede aplicar a la declaration de funciones. Para fund () 
serla algo asl: 

extern int fund (int length, int width); 

Esta sentencia es equivalente a las declaraciones anteriores para fund () . Co¬ 
mo no hay cuerpo de funcion, el compilador debe tratarla como una declaration 
de funcion en lugar de como definicion. La palabra reservada extern es bastante 
superflua y optional para la declaration de funciones. Probablemente sea desafortu- 
nado que los disenadores de C no obligaran al uso de extern para la declaration 
de funciones; hubiera sido mas consistente y menos confuso (pero hubiera requerido 
teclear mas, lo cual probablemente explica la decision). 

Aqui hay algunos ejemplos mas de declaraciones: 

//: C02:Declare.cpp 

// Declaration & definition examples 

extern int i; // Declaration without definition 

extern float f (float) ; // Function declaration 

float b; // Declaration & definition 
float f (float a) { // Definition 

return a + 1.0; 

} 

int i; // Definition 

int h(int x) { // Declaration & definition 

return x + 1 ; 

} 

int main ( ) { 

b = 1.0; 
i = 2; 
f (b) ; 
h (i) ; 

} ///:- 


En la declaration de funciones, los identificadores de los argumentos son opcio- 
nales. En la definicion son necesarios (los identificadores se requieren solamente en 
C, no en C++). 

Incluir ficheros de cabecera 

La mayorla de las librerlas contienen un numero importante de funciones y varia¬ 
bles. Para ahorrar trabajo y asegurar la consistencia cuando se hacen declaraciones 
externas para estos elementos, C y C++ utilizan un artefacto llamado fichero de ca- 
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becera. Un fichero de cabecera es un fichero que contiene las declaraciones externas 
de una libreria; convencionalmente tiene un nombre de fichero con extension . h, 
como headerfile . h (no es dificil encontrar codigo mas antiguo con extensiones 
diferentes, como . hxx o . hpp, pero es cada vez mas raro). 

El programador que crea la libreria proporciona el fichero de cabecera. Para de- 
clarar las funciones y variables externas de la libreria, el usuario simplemente inclu- 
ye el fichero de cabecera. Para ello se utiliza la directiva de preprocesado #include. 
Eso le dice al preprocesador que abra el fichero de cabecera indicado e incluya el con- 
tenido en el lugar donde se encuentra la sentencia #include. Un #include puede 
indicar un fichero de dos maneras: mediante parentesis angulares ( < > ) o comillas 
dobles. 

Los ficheros entre parentesis angulares, como: 

#include <header> 


hacen que el preprocesador busque el fichero como si fuera particular a un pro- 
yecto, aunque normalmente hay un camino de busqueda que se especifica en el 
entorno o en la linea de comandos del compilador. El mecanismo para cambiar el 
camino de busqueda (o ruta) varia entre maquinas, sistemas operativos, e imple- 
mentaciones de C++ y puede que requiera un poco de investigacion por parte del 
programador. 

Los ficheros entre comillas dobles, como: 

#include "header" 


le dicen al preprocesador que busque el fichero en (de acuerdo a la especificacion) 
«un medio de definicion de implementacion», que normalmente significa buscar el 
fichero de forma relativa al directorio actual. Si no lo encuentra, entonces la directiva 
se preprocesada como si tuviera parentesis angulares en lugar de comillas. 

Para incluir el fichero de cabecera iostream, hay que escribir: 

#include <iostream> 


El preprocesador encontrara el fichero de cabecera iostream (a menudo en un 
subdirectorio llamado «include») y lo incluira. 

Formato de inclusion del estandar C++ 

A medida que C++ evolucionaba, los diferentes fabricantes de compiladores ele- 
gian diferentes extensiones para los nombres de ficheros. Ademas, cada sistema ope¬ 
rative tiene sus propias restricciones para los nombres de ficheros, en particular la 
longitud. Estas caracteristicas crearon problemas de portabilidad del codigo fuente. 
Para limar estos problemas, el estandar usa un formato que permite los nombres de 
ficheros mas largos que los famosos ocho caracteres y permite eliminar la extension. 
Por ejemplo en vez de escribir iostream. h en el estilo antiguo, que se asemejaria a 
algo asi: 

#include <iostream.h> 


ahora se puede escribir: 
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#include <iostream> 


El traductor puede implementar la sentencia del include de tal forma que se 
amolde a las necesidades de un compilador y sistema operativo particular, aunque 
sea necesario truncar el nombre y anadir una extension. Evidentemente, tambien 
puede copiar las cabeceras que ofrece el fabricante de su compilador a otras sin ex- 
tensiones si quiere usar este nuevo estilo antes de que su fabricante lo soporte. 

Las librerias heredadas de C aun estan disponibles con la extension tradicional 
« . h». Sin embargo, se pueden usar con el estilo de inclusion mas moderno colocando 
una «c» al nombre. Es decir: 

#include <stdio.h> 

#include <stdlib.h> 


Se transformaria en: 

#include <cstdio> 
#include <cstdlib> 


Y asi para todas cabeceras del C Estandar. Eso proporciona al lector una distin- 
cion interesante entre el uso de librerias C versus C++. 

El efecto del nuevo formato de include no es identico al antiguo: usar el « . h» da 
como resultado una version mas antigua, sin plantillas, y omitiendo el «. h» le ofre¬ 
ce la nueva version con plantillas. Normalmente podria tener problemas si intenta 
mezclar las dos formas de inclusion en un mismo programa. 


2.2.2. Enlazado 

El enlazador ( linker ) agrupa los modulos objeto (que a menudo tienen extensio- 
nes como . o 6 . ob j ), generados por el compilador, en un programa ejecutable que 
el sistema operativo puede cargar y ejecutar. Es la ultima fase del proceso de compi¬ 
lacion. 

Las caracteristicas del enlazador varian de un sistema a otro. En general, simple- 
mente se indican al enlazador los nombres de los modulos objeto, las librerias que se 
desean enlazar y el nombre del ejecutable de salida. Algunos sistemas requieren que 
sea el programador el que invoque al enlazador, aunque en la mayoria de los paque- 
tes de C++ se llama al enlazador a traves del compilador. En muchas situaciones, de 
manera transparente. 

Algunos enlazadores antiguos no buscaban ficheros objeto mas de una vez y bus- 
caban en la lista que se les pasaba de izquierda a derecha. Esto significa que el orden 
de los ficheros objeto y las librerias puede ser importante. Si se encuentra con algun 
problema misterioso que no aparece hasta el proceso de enlazado, una posible razon 
es el orden en el que se indican los ficheros al enlazador. 


2.2.3. Uso de librerias 

Ahora que ya conoce la terminologia basica, puede entender como utilizar una 
libreria. Para usarla: 
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1. Se incluye el fichero de cabecera de la libreria. 

2. Se usan las funciones y las variables de la libreria. 

3. Se enlaza la libreria junto con el programa ejecutable. 

Estos pasos tambien se aplican cuando los modulos objeto no se combinan para 
formar una libreria. Incluir el fichero cabecera y enlazar los modulos objeto es la base 
para la compilacion separada en C y en C++. 

Como busca el enlazador una libreria 

Cuando se hace una refencia externa a una funcion o una variable en C o C++, 
al enlazador, una vez encontrada esta referenda, puede hacer dos cosas. Si todavia 
no ha encontrado la definicion de la funcion o variable, ahade el identificador a su 
lista de «referencias no resueltas». Si el enlazador ya habia encontrado la definicion, 
se resuelve la referenda. 

Si el enlazador no puede encontrar la definicion en la lista de modulos objeto, 
busca en las librerias. Las librerias tienen algun tipo de indexacion para que el en¬ 
lazador no necesite buscar en todos los modulos objeto en la libreria - solamente 
mira en el indice. Cuando el enlazador encuentra una definicion en una libreria, el 
modulo objeto entero, no solo la definicion de la funcion, se enlaza al programa eje¬ 
cutable. Dese cuenta que no se enlaza la libreria completa, tan solo el modulo objeto 
de la libreria que contiene la definicion que se necesita (de otra forma los programas 
se volverian innecesariamente largos). Si se desea minimizar el tamano del progra¬ 
ma ejecutable, se deberia considerar poner una unica funcion en cada fichero fuente 
cuando se construyan librerias propias. Esto requiere mas trabajo de edicion, 4 pero 
puede ser muy util para el usuario. 

Debido a que el enlazador busca los ficheros en el orden que se le dan, se puede 
prevenir el uso de una funcion de una libreria insertando un fichero con su propia 
funcion, usando el mismo nombre de funcion, en la lista antes de que aparezca el 
nombre de la libreria. Cuando el enlazador resuelva cualquier referenda a esa fun¬ 
cion encontrando la funcion antes de buscar en la libreria, se utilizara su funcion 
en lugar de la que se encuentra en la libreria. Eso tambien puede ser una fuente de 
errores, y es la clase de cosas que se puede evitar usando los espacios de nombres 
( namespaces ) de C++. 

Anadidos ocultos 

Cuando se crea un programa ejecutable en C/C++, ciertos elementos se enlazan 
en secreto. Uno de estos elementos es el modulo de arranque, que contiene rutinas 
de inicializacion que deben ejecutarse cada vez que arranca un programa C o C++. 
Estas rutinas preparan la pila e inicializan ciertas variables del programa. 

El enlazador siempre busca la libreria estandar para las versiones compiladas de 
cualquier funcion «estandar» llamada en el programa. Debido a que se busca siem¬ 
pre en la libreria estandar, se puede usar cualquier cosa de esta libreria simplemente 
anadiendo a su programa la cabecera apropiada; no necesita indicar donde hay que 
buscar la libreria estandar. Las funciones de flujo de entrada-salida (iostream), por 
ejemplo, estan en la Libreria Estandar de C++. Para usarla, solo debe incluir el fichero 
de cabecera <iostream>. 

4 Yo le recomendaria usar Perl o Python para automatizar estas tareas como parte de su proceso de 
empaquetamiento de librerias (ver www.Perl.org 6 www.Python.org). 
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Si se esta usando una libreria, se debe anadir explicitamente su nombre de esta a 
la lista de ficheros manejados por el enlazador. 

Uso de librerfas C piano 

Aunque este escribiendo codigo en C++, nada le impide usar librerias de C. De 
hecho, toda la libreria de C esta incluida por defecto en el C++ Estandar. Hay una 
cantidad tremenda de trabajo ya realizado en esas librerias que le pueden ahorrar un 
monton de tiempo. 

Este libro usara la libreria Estandar de C++ cuando sea necesario (y por lo tan- 
to la de C), pero solo se utilizaran funciones de la libreria estandar, para asegurar 
la portabilidad de los programas. En los pocos casos en los que las funciones no 
sean de C++ estandar, se intentara que sean funciones compatibles con POSIX. PO- 
SIX es un estandar basado en el esfuerzo por conseguir la estandarizacion de Unix, 
que incluye funciones que van mas alia del ambito de las librerias de C++. Normal- 
mente puede esperar encontrar funciones POSIX en plataformas Unix (en particular, 
GNU/Linux), y a menudo en sistemas DOS/Windows. Por ejemplo, si esta usando 
hilos ( threads ) sera mejor usar la libreria de hilos compatible con POSIX ya que su 
codigo sera mas facil de entender, portar y mantener (y la libreria de hilos usara los 
servicios que ofrece el sistema operativo, si es que estan soportados). 


2.3. Su primer programa en C++ 

Ahora ya tiene suficientes conocimientos para crear y compilar un programa. Este 
programa usara las clases de flujo de entrada-salida (iostream) del C++ estandar. 
iostream es capaz de leer y escribir en ficheros o en la entrada y salida estandar 
(que suele ser la consola, pero que puede ser redirigida a ficheros o dispositivos). En 
este programa simple, se usa un objeto stream (flujo) para imprimir un mensaje en 
pantalla. 

2.3.1. Uso de las clases iostream 

Para declarar las funciones y los datos externos que contenga la clase iostream 
hay que incluir el fichero de cabecera de la siguiente manera: 

finclude <iostream> 

El primer programa usa el concepto de salida estandar, que significa «un lugar 
de proposito general, al que se le pueden enviar cosas». Vera otros ejemplos que 
utilizan la salida estandar de otras formas, pero aqui simplemente usaremos la con- 
sola. El paquete iostream define una variable (un objeto) llamado cout de forma 
automatica que es capaz de enviar todo tipo de datos a la salida estandar. 

Para enviar datos a la salida estandar, se usa el operador <<.Los programadores 
de C lo conocen como operador de «desplazamiento a la izquierda», que se explica- 
ra en el siguiente capitulo. Baste decir que el desplazamiento a la izquierda no tiene 
nada que ver con la salida. Sin embargo, C++ permite que los operadores sean sobre- 
cargados. Cuando se sobrecarga un operador, se le da un nuevo significado siempre 
que dicho operador se use con un objeto de determinado tipo. Con los objetos de 
iostream, el operador << significa «enviar a». Por ejemplo: 

cout << "howdy!"; 


47 
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envia la cadena «howdy!» al objeto llamado cout (que es un diminutivo de con¬ 
sole output» (salida por consola). 

De momento ya hemos visto suficiente sobrecarga de operadores como para po- 
der empezar. El Capitulo 12 cubre la sobrecarga de operadores con detalle. 


2.3.2. Espacios de nombres 

Como se menciona en el Capitulo 1, uno de los problemas del lenguaje C es que 
«nos quedamos sin nombres» para funciones e identificadores cuando los progra- 
mas llegan a ser de cierto tamano. Por supuesto que realmente no nos quedamos 
sin nombres; aunque se hace mas dificil pensar en nombres nuevos despues de un 
rato. Y todavia mas importante, cuando un programa alcanza cierto tamano es nor¬ 
mal fragmentarlo en trozos mas pequenos cada uno de los cuales es mantenido por 
diferentes personas o grupos. Como C solo tiene un ruedo para lidiar con todos los 
identificadores y nombres de funcion, trae como consecuencia que todos los desa- 
rrolladores deben tener cuidado de no usar accidentalmente los mismos nombres en 
situaciones en las que pueden ponerse en conflicto. Esto se convierte en una perdida 
de tiempo, se hace tedioso y en ultimo termino, es mas caro. 

El C++ Estandar tiene un mecanismo para impedir estas colisiones: la palabra 
reservada namespace (espacio de nombres). Cada conjunto de definiciones de una 
libreria o programa se «envuelve» en un espacio de nombres, y si otra definicion 
tiene el mismo nombre, pero esta en otro espacio de nombres, entonces no se produce 
colision. 

El espacio de nombres es una herramienta util y conveniente, pero su presen- 
cia implica que debe saber usarla antes de escribir un programa. Si simplemente 
escribe un fichero de cabecera y usa algunas funciones u objetos de esa cabecera, 
probablemente reciba extranos mensajes cuando compile el programa, debido a que 
el compilador no pueda encontrar las declaraciones de los elementos del fichero de 
cabecera. Despues de ver este mensaje un par de veces se le hara familiar su signi- 
ficado (que es: Usted ha incluido el fichero de cabecera pero todas las declaraciones estdn 
sin un espacio de nombres y no le dijo al compilador que queria usar las declaraciones en ese 
espacio de nombres). 

Hay una palabra reservada que le permite decir «quiero usar las declaraciones 
y/o definiciones de este espacio de nombres». Esa palabra reservada, bastante apro- 
piada por cierto, es using. Todas las librerias de C++ Estandar estan incluidas en 
un unico espacio de nombres, que es std (por «standard»). Como este libro usa la 
libreria estandar casi exclusivamente, vera la siguiente directiva using en casi todos 
los programas. 

using namespace std; 

Esto significa que quiere usar todos los elementos del espacio de nombres llama¬ 
do std. Despues de esta sentencia, ya no hay que preocuparse de si su componente 
o libreria particular pertenece a un espacio de nombres, porque la directiva using 
hace que el espacio de nombres este disponible para todo el fichero donde se escribio 
la directiva using. 

Exponer todos los elementos de un espacio de nombres despues de que alguien 
se ha molestado en ocultarlos, parece contraproducente, y de hecho, el lector debera 
tener cuidado si considera hacerlo (como aprendera mas tarde en este libro). Sin 
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embargo, la directiva using expone solamente los nombres para el fichero actual, 
por lo que no es tan drastico como suena al principio. (pero pienselo dos veces antes 
de usarlo en un fichero cabecera, eso es temerario). 

Existe una relacion entre los espacios de nombres y el modo en que se incluyes los 
ficheros de cabecera. Antes de que se estandarizara la nueva forma de inclusion de 
los ficheros cabecera (sin el «. h» como en <iostream>), la manera tipica de incluir 
un fichero de cabecera era con el «.h» como en <iostream.h>. En esa epoca los 
espacios de nombres tampoco eran parte del lenguaje, por lo que para mantener una 
compatibilidad hacia atras con el codigo existente, si se escribia: 

finclude <iostream.h> 


En realidad, significaba: 

#include <iostream> 
using namespace std; 


Sin embargo en este libro se usara la forma estandar de inclusion (sin el «. h») y 
haciendo explicita la directiva using. 

Por ahora, esto es todo lo que necesita saber sobre los espacios de nombres, pero 
el Capitulo 10 cubre esta materia en profundidad. 


2.3.3. Fundamentos de la estructura de los programa 

Un programa C o C++ es una coleccion de variables, definiciones de funcion, y 
llamada a funciones. Cuando el programa arranca, ejecuta el codigo de inicializacion 
y llama a una funcion especial, «main ()», que es donde debe colocarse el codigo 
principal del programa. 

Como se menciono anteriormente, una definicion de funcion consiste en un valor 
de retorno (que se debe especificar en C++), un nombre de funcion, una lista de 
argumentos, y el codigo de la funcion entre llaves. Aqui hay un ejemplo de definicion 
de funcion: 

int funcion() { 

// oCdigo de la ofuncin iaqu (esto es un coraentario) 

} 


La funcion de arriba tiene una lista vacia de argumentos y un cuerpo que contiene 
unicamente un comentario. 

Puede haber varios pares de llaves en la definicion de una funcion, pero siempre 
debe haber al menos dos que envuelvan todo el cuerpo de la funcion. Como main () 
es una funcion, debe seguir esas reglas. En C++, main () siempre devuelve un valor 
de tipo int (entero). 

C y C++ son lenguajes de formato libre. Con un par de excepciones, el compilador 
ignora los espacios en bianco y los saltos de linea, por lo que hay que determinar el 
final de una sentencia. Las sentencias estan delimitadas por punto y coma. 

Los comentarios en C empiezan con / * y finalizan con */. Pueden incluir saltos 
de linea. C++ permite este estilo de comentarios y anade la doble barra inclinada: 
/ /. La / / empieza un comentario que finaliza con el salto de linea. Es mas util que 
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/ * * / y se usa ampliamente en este libro. 


2.3.4. «Hello, World!» 

Y por fin, el primer programa: 

//: C02:Hello.cpp 
// Saying Hello with C++ 

#include <iostream> // Stream declarations 

using namespace std; 

int main () { 

cout << "Hello, World! I am " 

<< 8 << " Today!" << endl; 

} ///:- 


El objeto cout maneja una serie de argumentos por medio de los operadores 
«, que imprime los argumentos de izquierda a derecha. La funcion especial en¬ 
dl provoca un salto de linea. Con los iostreams se puede encadenar una serie de 
argumentos como aqui, lo que hace que sea una clase facil de usar. 

En C, el texto que se encuentra entre comillas dobles se denomina «cadena» 
(string). Sin embargo, la libreria Estandar de C++ tiene una poderosa clase llama- 
da string para manipulation de texto, por lo que usaremos el termino mas preciso 
array de caracteres para el texto que se encuentre entre dobles comillas. 

El compilador pide espacio de memoria para los arrays de caracteres y guarda 
el equivalente ASCII para cada caracter en este espacio. El compilador finaliza auto- 
maticamente este array de caracteres anadiendo el valor 0 para indicar el final. 

Dentro del array de caracteres, se pueden insertar caracteres especiales usando 
las secuencias de escape. Consisten en una barra invertida (\) seguida de un codigo 
especial, por ejemplo \n significa salto de linea. El manual del compilador o la guia 
concreta de C ofrece una lista completa de secuencia; entre otras se incluye: \t (ta- 
bulador), \\ (barra invertida), y \b (retroceso). 

Tenga en cuenta que la sentencia puede continuar en otras lineas, y la sentencia 
completa termina con un punto y coma. 

Los argumentos de tipo array de caracteres y los numeros constantes estan mez- 
clados en la sentencia cout anterior. Como el operador << esta sobrecargado con 
varios significados cuando se usa con cout, se pueden enviar distintos argumentos 
y cout se encargara de mostrarlos. 

A lo largo de este libro notara que la primera linea de cada fichero es un comen- 
tario (empezando normalmente con / /), seguido de dos puntos, y la ultima linea 
de cada listado de codigo acaba con un comentario seguido de «/-». Se trata de 
una una tecnica que uso para extraer facilmente information de los ficheros fuen- 
te (el programa que lo hace se puede encontrar en el Volumen 2 de este libro, en 
www.BruceEckel.com). La primera linea tambien tiene el nombre y localization del 
fichero, por lo que se puede localizar facilmente en los ficheros de codigo fuente del 
libro (que tambien se puede descargar de www.BruceEckel.com). 













Volumenl" — 2012/1/12 — 13:52 — page 51 — #89 


2.4. Mas sobre iostreams 


2.3.5. Utilizar el compilador 

Despues de descargar y desempaquetar el codigo fuente del libro, busque el pro- 
grama en el subdirectorio C02. Invoque el compilador con Hello . cpp como para- 
metro. La mayoria de los compiladores le abstraen de todo el proceso si el programa 
consta de un unico fichero. Por ejemplo, para usar el compilador GNU C++ (que esta 
disponible en Internet), escriba: 


g++ Hello.cpp 


Otros compiladores tendran una sintaxis similar aunque tendra que consultar la 
documentacion para conocer los detalles particulares. 


2.4. Mas sobre iostreams 

Hasta ahora solo ha visto los aspectos mas rudimentarios de las clases iostream. 
El formateo de salida que permiten los iostreams tambien incluyen caracteristicas co¬ 
mo el formateo de numeros en decimal, octal, y hexadecimal. Aqui tiene otro ejemplo 
del uso de los iostreams: 

//: C02:Stream2.cpp 
// More streams features 

#include <iostream> 

using namespace std; 

int main() { 

// Specifying formats with manipulators: 
cout << "a number in decimal: " 

<< dec << 15 << endl; 

cout << "in octal: " << oct << 15 << endl; 
cout << "in hex: " << hex << 15 << endl; 
cout << "a floating-point number: " 

<< 3.14159 << endl; 

cout << "non-printing char (escape): " 

<< char (27) << endl; 

} /// : ~ 


Este ejemplo muestra como la clase iostreams imprime numeros en decimal, 
octal, y hexadecimal usando manipuladores (los cuales no imprimen nada, pero cam- 
bian el estado del flujo de salida). El formato de los numeros en punto flotante lo 
determina automaticamente el compilador. Ademas, se puede enviar cualquier ca- 
racter a un objeto stream usando un molde (cast) a char (un char es un tipo de datos 
que manipula un solo caracter). Este molde parece una llamada a funcion: char (), 
devuelve un valor ASCII. En el programa de arriba, el char (27) envia un «escape» 
a cout. 


2.4.1. Concatenar vectores de caracteres 

Una caracteristica importante del preprocesador de C es la concatenacion de arrays 
de caracteres. Esta caracteristica se usa en algunos de los ejemplos de este libro. Si se 
colocan juntos dos arrays de caracteres entrecomillados, sin signos de puntuacion 
entre ellos, el compilador los pegara en un unico array de caracteres. Esto es particu- 
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larmente util cuando los listados de codigo tienen restricciones de anchura. 

//: C02:Concat.cpp 

// Character array Concatenation 

#include <iostream> 

using namespace std; 

int main () { 

cout << "This is far too long to put on a " 

"single line but it can be broken up with " 

"no ill effects\nas long as there is no " 

"punctuation separating adjacent character " 

"arrays.\n"; 

} ///:~ 


A1 principio, el codigo de arriba puede parecer erroneo porque no esta el ya fa¬ 
miliar punto y coma al final de cada linea. Recuerde que C y C++ son lenguajes de 
formato libre, y aunque normalmente vera un punto y coma al final de cada linea, el 
requisito real es que haya un punto y coma al final de cada sentencia, por lo que es 
posible encontrar una sentencia que ocupe varias lineas. 


2.4.2. Leer de la entrada 

Las clases iostream proporcionan la habilidad de leer de la entrada. El objeto 
usado para la entrada estandar es cin (de «console input»). cin normalmente espera 
la entrada de la consola, pero esta entrada se puede redirigir desde otras fuentes. Un 
ejemplo de redirection se muestra mas adelante en este capitulo. 

El operador que usa iostream con el objeto cin es >>. Este operador espera 
como parametro algun tipo de entrada. Por ejemplo, si introduce un parametro de 
tipo entero, el espera un entero de la consola. Aqui hay un ejemplo: 


//: C02:Numconv.cpp 

// Converts decimal to octal and hex 

#include <iostream> 

using namespace std; 


int main () { 

int number; 
cout << "Enter 
cin >> number; 
cout << "value 
<< oct << 
cout << "value 
<< hex << 

} ///:- 


a decimal number: 

in octal = 0" 
number << endl; 
in hex = Ox" 
number << endl; 


II . 


Este programa convierte un numero introducido por el usuario en su representa¬ 
tion octal y hexadecimal. 
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2.4.3. Llamar a otros programas 

Mientras que el modo tipico de usar un programa que lee de la entrada estandar 
y escribe en la salida estandar es dentro de un shell script Unix o en un fichero batch 
de DOS, cualquier programa se puede llamar desde dentro de un programa C o C++ 
usando la llamada a la funcion estandar system () que esta declarada en el fichero 
de cabecera <cstdlib> :. 

//: C02:CallHello.cpp 
// Call another program 

#include <cstdlib> // Declare "systemO" 

using namespace std; 

int main() { 

system("Hello" ) ; 

1 /// : ~ 


Para usar la funcion system (), hay que pasarle un array de caracteres con la 
linea de comandos que se quiere ejecutar en el prompt del sistema operativo. Puede 
incluir los parametros que utilizaria en la linea de comandos, y el array de caracteres 
se puede fabricar en tiempo de execution (en vez de usar un array de caracteres esta- 
tico como se mostraba arriba). El comando se ejecuta y el control vuelve al programa. 

Este programa le muestra lo facil que es usar C piano en C++; solo incluya la 
cabecera y utilice la funcion. Esta compatibilidad ascendente entre el C y el C++ es 
una gran ventaja si esta aprendiendo C++ y ya tenia conocimientos de C. 


2.5. Introducion a las cadenas 

Un array de caracteres puede ser bastante util, aunque esta bastante limitado. 
Simplemente son un grupo de caracteres en memoria, pero si quiere hacer algo util, 
debe manejar todos los pequenos detalles. Por ejemplo, el tamano de un array de 
caracteres es fijo en tiempo de compilation. Si tiene un array de caracteres y quiere 
anadirle mas caracteres, tendra que saber mucho sobre ellos (incluso manejo dina- 
mico de memoria, copia de array de caracteres, y concatenation) antes de conseguir 
lo que desea. Esta es exactamente la clase de cosas que deseariamos que hiciera un 
objeto por nosotros. 

La clase string (cadena) del C++ Estandar ha sido disenada para que se encar- 
gue y oculte las manipulaciones de bajo nivel de los arrays de caracteres que antes 
tenia que realizar el programador de C. Estas manipulaciones han sido una fuente 
de constantes perdidas de tiempo y errores desde los origenes del lenguaje C. Aun¬ 
que hay un capitulo entero dedicado a la clase string en el Volumen 2 de este libro, 
las cadenas son tan importantes y facilitan tanto la vida que las presentare aqui para 
usarlas lo antes posible en el libro. 

Para usar las cadenas debe incluir el fichero de cabecera <string>. La clase s- 
tring se encuentra en el espacio de nombres std por lo que se necesita usar la 
directiva using. Gracias a la sobrecarga de operadores, la sintaxis del uso de las 
cadenas es muy intuitiva: 

//: C02:HelloStrings.cpp 

// The basics of the Standard C++ string class 

#include <string> 
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#include <iostream> 

using namespace std; 

int main() { 

string si, s2; // Empty strings 

string s3 = "Hello, World."; // Initialized 

string s4("I am"); // Also initialized 

s2 = "Today"; // Assigning to a string 

si = s3 + " " + s4; // Combining strings 

si += " 8 "; // Appending to a string 

cout << si + s2 + "!" << endl; 

} ///:- 


Las dos primeras cadenas, s 1 y s 2 empiezan estando vacias, mientras que s 3 y 
s4 muestran dos formas de inicializar los objetos string con arrays de caracteres 
(puede inicializar objetos string igual de facil con otros objetos string). 

Se puede asignar a un objeto string usando =. Eso sustituye el contenido pre- 
vio de la cadena con lo que se encuentra en el lado derecho de la asignacion, y no 
hay que preocuparse de lo que ocurre con el contenido anterior porque se controla 
automaticamente. Para combinar las cadenas simplemente debe usar el operador de 
suma «+», que tambien le permite concatenar cadenas (strings) con arrays de ca¬ 
racteres. Si quiere anadir una cadena o un array de caracteres a otra cadena, puede 
usar el operador +=. Finalmente, dese cuenta que iostream sabe como tratar las 
cadenas, por lo que usted puede enviar una cadena (o una expresion que produzca 
un string, que es lo que sucede con si + s2 + " ! ">) directamente a cout para 
imprimirla. 


2.6. Lectura y escritura de ficheros 

En C, el proceso de abrir y manipular ficheros requeria un gran conocimiento 
del lenguaje para prepararle para la complejidad de las operaciones. Sin embargo, la 
libreria iostream de C++ proporciona una forma simple de manejar ficheros, y por 
eso se puede presentar mucho antes de lo que se haria en C. 

Para poder abrir un fichero para leer y escribir, debe incluir la libreria f stream. 
Aunque eso implica la inclusion automatica de la libreria iostream, es prudente 
incluir iostream si planea usar cin, cout, etc. 

Para abrir un fichero para lectura, debe crear un objeto if stream que se usara 
como cin. Para crear un fichero de escritura, se crea un objeto ofstream que se 
comporta como cout. Una vez que tiene abierto el fichero puede leer o escribir en 
el como si usara cualquier objeto iostream. Asi de simple, que es el objetivo, por 
supuesto. 

Una de funciones las mas utiles de la libreria iostream es getline (), que 
permite leer una linea (terminada en nueva linea) y guardarla en un objeto string 
5 . El primer argumento es el objeto if stream del que se va a leer la informacion y 
el segundo argumento es el objeto string. Cuando termina la llamada a la funcion, 
el objeto string contiene la linea capturada. 

Aqui hay un ejemplo que copia el contenido de un fichero en otro. 

5 Actualmente existen variantes de getline (), que se discutiran profusamente en el capitulo de 
iost reams en el Volumen 2 
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//: C02:Scopy.cpp 

// Copy one file to another, a line at a time 

#include <string> 

#include <fstream> 
using namespace std; 

int main () { 

ifstream in("Scopy.cpp"); // Open for reading 

ofstream out("Scopy2.cpp"); // Open for writing 

string s; 

while (getline(in, s)) // Discards newline char 

out << s << "\n"; // ... must add it back 
} ///:- 


Para abrir los ficheros, unicamente debe controlar los nombres de fichero que se 
usan en la creacion de los objetos ifstream y of stream. 

Aqui se presenta un nuevo concepto: el bucle while. Aunque sera explica do en 
detalle en el siguiente capitulo, la idea basica consiste en que la expresion entre pa- 
rentesis que sigue al while controla la ejecucion de la sentencia siguiente (pueden 
ser multiples sentencias encerradas entre Haves). Mientras la expresion entre paren- 
tesis (en este caso getline (in, s) produzca un resultado «verdadero», las sen¬ 
tencias controladas por el while se ejecutaran. getline ( ) devuelve un valor que 
se puede interprer como «verdadero» si se ha leido otra linea de forma satisfactoria, 
y «falso» cuando se llega al final de la entrada. Eso implica que el while anterior lee 
todas las lineas del fichero de entrada y las envia al fichero de salida. 

getline ( ) lee los caracteres de cada linea hasta que descubre un salto de linea 
(el caracter de terminacion se puede cambiar pero eso no se vera hasta el capitulo 
sobre iostreams del Volumen 2). Sin embargo, descarta el caracter de nueva linea 
y no lo almacena en el objeto string. Por lo que si queremos copiar el fichero de for¬ 
ma identica al original, debemos anadir el caracter de nueva linea como se muestra 
arriba. 

Otro ejemplo interesante es copiar el fichero entero en un unico objeto string: 

//: C02:Fillstring.cpp 

// Read an entire file into a single string 

#include <string> 

#include <iostream> 

#include <fstream> 
using namespace std; 

int main() { 

ifstream in("Fillstring.cpp"); 
string s, line; 
while (getline(in, line)) 
s += line + "\n"; 
cout << s; 

} ///:- 


Debido a la naturaleza dinamica de los strings, no hay que preocuparse de la 
cantidad de memoria que hay que reservar para el string. Simplemente hay que 
anadir cosas y el string ira expandiendose para dar cabida a lo que le introduzca. 
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Una de las cosas agradables de poner el fichero entero en una cadena es que la 
clase string proporciona funciones para la busqueda y manipulacion que le per- 
miten modificar el fichero como si fuera una simple linea. Sin embargo, tiene sus 
limitaciones. Por un lado, a menudo, es conveniente tratar un fichero como una co- 
leccion de lineas en vez de un gran bloque de texto. Por ejemplo, si quiere anadir 
numeracion de lineas es mucho mas facil si tiene un objeto string distinto para 
cada linea. Para realizarlo, necesitamos otro concepto. 


2.7. Introduction a los vectores 

Con cadenas, podemos rellenar un objeto string sin saber cuanta memoria se 
va a necesitar. El problema de introducir lineas de un fichero en objetos strin- 
g es que se sabe cuantas cadenas habra - solamente lo sabemos cuando ya hemos 
leido el fichero entero. Para resolver este problema necesitamos un nuevo tipo de 
datos que pueda crecer automaticamente para contener las cadenas que le vayamos 
introduciendo. 

De hecho, ^por que limitarnos a manejar objetos string? Parece que este tipo 
de problema - no saber la cantidad de cosas a manejar mientras esta escribiendo el 
problema - ocurre a menudo. Y este objeto «contenedor» podria resultar mas util si 
pudiera manejar cualquier clase de objeto. Afortunadamente, la Libreria Estandar de 
C++ tiene una solucion: las clases contenedor ( container ). Las clases contenedor son 
uno de los puntos fuertes del Estandar C++. 

A menudo existe un poco de confusion entre los contenedores y los algoritmos 
en la libreria Estandar de C++, y la STL. La Standard Template Library fue el nombre 
que uso Alex Stepanov (que en aquella epoca estaba trabajando en Hewlett-Packard) 
cuando presento su libreria al Comite del Estandar C++ en el encuentro en San Die¬ 
go, California, en la primavera de 1994. El nombre sobrevivio, especialmente des¬ 
pues de que HP decidiera dejarlo disponible para la descarga publica. Posterior- 
mente el comite integro las STL en la Libreria Estandar de C++ haciendo un gran 
numero de cambios. El desarrollo de las STL continua en Silicon Graphics (SGI; ver 
www.sgi.com/Technology/STL). Las SGI STL divergen de la Libreria Estandar de 
C++ en muchos detalles sutiles. Aunque es una creencia ampliamente generalizada, 
el C++ Estandar no "incluye" las STL. Puede ser confuso debido a que los contenedo¬ 
res y los algoritmos en el C++ Estandar tienen la misma raiz (y a menudo el mismo 
nombre) que en el SGI STL. En este libro, intentare decir «la libreria Estandar de 
C++» o «Libreria Estandar de contenedores», o algo similar y eludire usar el termino 
STL. 

A pesar de que la implementacion de los contenedores y algoritmos de la Libre¬ 
ria Estandar de C++ usa algunos conceptos avanzados, que se cubren ampliamente 
en dos largos capitulos en el segundo volumen de este libro, esta libreria tambien 
puede ser potente sin saber mucho sobre ella. Es tan util que el mas basico de los 
contenedores estandar, el vector, se introduce en este capitulo y se usara a lo largo 
de todo el libro. Vera que puede hacer muchas cosas con el vector y no saber co¬ 
mo esta implementado (de nuevo, uno de los objetivos de la POO). Los programas 
que usan vector en estos primeros capitulos del libro no son exactamente como los 
haria un programador experimentado, como comprobara en el volumen 2. Aun asi, 
encontrara que en la mayoria de los casos el uso que se hace es adecuado. 

La clase vector es una plantilla, lo que significa que se puede aplicar a tipos de 
datos diferentes. Es decir, se puede crear un vector de figuras, un vector de 
gatos, un vector de strings, etc. Basicamente, con una plantilla se puede crear 
un vector de «cualquier clase». Para decir le al compilador con que clase trabajara 
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(en este caso que va a manejar el vector), hay que poner el nombre del tipo deseado 
entre «llaves angulares». Por lo que un vector de string se denota como vect- 
or<str ing>. Con eso, se crea un vector a medida que solamente contendra objetos 
string, y recibira un mensaje de error del compilador si intenta poner otra cosa en 
el. 

Como el vector expresa el concepto de «contenedor», debe existir una manera 
de meter cosas en el y sacar cosas de el. Para anadir un nuevo elemento al final del 
vector, se una el metodo push_back (). Recuerde que, como es un metodo, hay que 
usar un para invocarlo desde un objeto particular. La razon de que el nombre de 
la funcion parezca un poco verboso - push_back () en vez de algo mas simple co¬ 
mo put - es porque existen otros contenedores y otros metodos para poner nuevos 
elementos en los contenedores. Por ejemplo, hay un insert () para poner algo en 
medio de un contenedor. vector la soporta pero su uso es mas complicado y no 
necesitamos explorarla hasta el segundo volumen del libro. Tambien hay un push- 
_f ront () (que no es parte de vector) para poner cosas al principio. Hay muchas 
mas funciones miembro en vector y muchos mas contenedores en la Libreria Es- 
tandar, pero le sorprendera ver la de cosas que se pueden hacer con solo un par de 
caracteristicas basicas. 

Asi que se pueden introducir elementos en un vector con push_back () pero 
icomo puede sacar esos elementos? La solution es inteligente y elegante: se usa la so- 
brecarga de operadores para que el vector se parezca a un array. El array (que sera 
descrito de forma mas completa en el siguiente capitulo) es un tipo de datos que esta 
disponible practicamente en cualquier lenguaje de programacion por lo que debe- 
ria estar familiarizado con el. Los arrays son agregados lo que significa que consisten 
en un numero de elementos agrupados. La caracteristica distintiva de un array es 
que estos elementos tienen el mismo tamano y estan organizados uno junto a otro. Y 
todavia mas importante, que se pueden seleccionar mediante un indice, lo que signi¬ 
fica que puede decir: «Quiero el elemento numero n» y el elemento sera producido, 
normalmente de forma rapida. A pesar de que existen excepciones en los lenguajes 
de programacion, normalmente se indica la «indexacion» mediante corchetes, de tal 
forma que si se tiene un array a y quiere obtener el quinto elemento, solo tiene que 
escribir a [ 4 ] (fijese en que la indexation siempre empieza en cero). 

Esta forma compacta y poderosa de notation indexada se ha incorpora do al ve¬ 
ctor mediante la sobrecarga de operadores como el << y el >> de los iostreams. 
De nuevo, no hay que saber como se ha implementado la sobrecarga de operadores 
- lo dejamos para un capitulo posterior - pero es util que sea consciente que hay 
algo de magia detras de todo esto para conseguir que los corchetes funcionen con el 
vector. 

Con todo esto en mente, ya puede ver un programa que usa la clase vector. 
Para usar un vector, hay que incluir el fichero de cabecera <vector> : 

//: C02:Fillvector.cpp 

// Copy an entire file into a vector of string 

#include <string> 

#include <iostream> 

#include <fstream> 

#include <vector> 
using namespace std; 

int main() { 

vector<string> v; 

ifstream in ( "Fillvector.cpp"); 

string line; 
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while (getline(in, line)) 

v.push_back(line); // Add the line to the end 
// Add line numbers: 
for(int i = 0; i < v.sizeO; i++) 
cout << i << " << v[i] << endl; 

} ///:- 


Casi todo este programa es similar al anterior; se abre un fichero abierto y se 
leen las lineas en objetos string (uno cada vez). Sin embargo, estos objetos string 
se introducen al final del vector v. Una vez que el bucle while ha terminado, el 
fichero entero se encuentra en memoria dentro de v. 

La siguiente sentencia en el programa es un bucle for. Es parecido a un bucle 
while aunque anade un control extra. Como en el bucle while, en el for hay una 
«expresion de control» dentro del parentesis. Sin embargo, esta expresion esta di- 
vidida en tres partes: una parte que inicializa, una que comprueba si hay que salir 
del bucle, y otra que cambia algo, normalmente da un paso en una secuencia de ele- 
mentos. Este programa muestra el bucle for de la manera mas habitual: la parte 
de inicializacion int i = 0 crea un entero i para usarlo como contador y le da el 
valor inicial de cero. La comprobacion consiste en ver si i es menor que el numero 
de elementos del vector v. (Esto se consigue usando la funcion miembro size () 
-tamaho- que hay que admitir que tiene un significado obvio) El ultimo trozo, usa el 
operador de «autoincremento» para aumentar en uno el valor de i. Efectivamente, 
i++ dice «coge el valor de i anadele uno y guarda el resultado en i». Conclusion: 
el efecto del bucle for es aumentar la variable i desde cero hasta el tamaho del v- 
ector menos uno. Por cada nuevo valor de i se ejecuta la sentencia del cout, que 
construye un linea con el valor de i (magicamente convertida a un array de carac- 
teres por cout), dos puntos, un espacio, la linea del fichero y el caracter de nueva 
linea que nos proporciona endl. Cuando lo compile y lo ejecute vera el efecto de 
numeracion de lineas del fichero. 

Debido a que el operador >> funciona con iostreams, se puede modificar facil- 
mente el programa anterior para que convierta la entrada en palabras separadas por 
espacios, en vez de lineas: 

//: C02:GetWords.cpp 

// Break a file into whitespace-separated words 

#include <string> 

#include <iostream> 

#include <fstream> 

#include <vector> 
using namespace std; 

int main() { 

vector<string> words; 
ifstream in("GetWords.cpp"); 
string word; 
while (in >> word) 

words.push_back(word) ; 
for(int i = 0; i < words.size (); i++) 
cout << words[i] << endl; 

} ///:~ 


La expresion: 
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while (in >> word) 


es la que consigue que se lea una «palabra» cada vez, y cuando la expresion se 
evalua como «falsa» significa que ha llegado al final del fichero. De acuerdo, deli- 
mitar una palabra mediante caracteres en bianco es un poco tosco, pero sirve como 
ejemplo sencillo. Mas tarde, en este libro, vera ejemplos mas sofisticados que le per- 
miten dividir la entrada de la forma que quiera. 

Para demostrar lo facil que es usar un vector con cualquier tipo, aqui tiene un 
ejemplo que crea un vector de enteros: 

//: C02:Intvector.cpp 

// Creating a vector that holds integers 

#include <iostream> 

#include <vector> 
using namespace std; 

int main() { 

vector<int> v; 
for (int i = 0; i < 10; i++) 
v.push_back(i); 

for (int i = 0; i < v.size(); i++) 
cout << v[i] << ", "; 

cout << endl; 

for(int i = 0; i < v.size(); i++) 
v[i] = v[i] * 10; // Assignment 
for(int i = 0; i < v.size (); i++) 
cout << v[i] << ", "; 

cout << endl; 

} ///:- 


Para crear un vector que maneje un tipo diferente basta con poner el tipo entre 
las llaves angulares (el argumento de las plantillas). Las plantillas y las librerias de 
plantillas pretenden ofrecer precisamente esta facilidad de uso. 

Ademas este ejemplo demuestra otra caracteristica esencial del vector en la ex¬ 
presion 

v[i] = v[i] * 10; 


Puede observar que el vector no esta limitado a meter cosas y sacarlas. Tambien 
puede asignar (es decir, cambiar) cualquier elemento del vector mediante el uso de 
los corchetes. Eso significa que el vector es un objeto util, flexible y de proposito 
general para trabajar con colecciones de objetos, y haremos uso de el en los siguientes 
capitulos. 


2.8. Resumen 

Este capitulo pretende mostrarle lo facil que puede llegar a ser la programacion 
orientada a objetos - si alguien ha hecho el trabajo de definir los objetos por usted. 
En este caso, solo hay que incluir el fichero de cabecera, crear los objetos y enviarles 
mensajes. Si los tipos que esta usando estan bien disenados y son potentes, entonces 



Volumenl" — 2012/1/12 — 13:52 — page 60 — #98 


Capitulo 2. Construir y usar objetos 


no tendra mucho trabajo y su programa resultante tambien sera potente. 

En este proceso para mostrar la sencillez de la POO cuando se usan librerias de 
clases, este capitulo, tambien introduce algunos de los tipos de datos mas basicos y 
utiles de la Libreria Estandar de C++: La familia de los iostreams (en particular 
aquellos que leen y escriben en consola y ficheros), la clase string, y la plantilla 
vector. Ha visto lo sencillo que es usarlos y ahora es probable que se imagine la 
de cosas que se pueden hacer con ellos, pero hay muchas mas cosas que son capaces 
de realizar 6 . A pesar de estar usando un pequeno subconjunto de la funcionalidad 
de estas herramientas en este principio del libro, supone un gran avance frente a 
los rudimentarios comienzos en el aprendizaje de un lenguaje de bajo nivel como 
C. Y aunque aprender los aspectos de bajo nivel de C es educativo tambien lleva 
tiempo. A1 final usted es mucho mas productivo si tiene objetos que manejen las 
caracteristicas de bajo nivel. Despues de todo, el principal objetivo de la POO es 
esconder los detalles para que usted pueda «pintar con una brocha mas gorda». 

Sin embargo, debido al alto nivel que la POO intenta tener, hay algunos aspectos 
fundamentales de C que no se pueden obviar, y de eso trata el siguiente capitulo. 


2.9. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Modifique Hello . cpp para que imprima su nombre y edad (o tamaho de pie, 
o la edad de su perro, si le gusta mas). Compile y ejecute el programa. 

2. Utilizando Stream2 . cpp y Numconv. cpp como guias, cree un programa que 
le pida el radio de un circulo y le muestre el area del mismo. Puede usar el 
operador * para elevar el radio al cuadrado. No intente imprimir el valor en 
octal o en hexadecimal (solo funciona con tipos enteros). 

3. Cree un programa que abra un fichero y cuente las palabras (separadas por 
espacios en bianco) que contiene. 

4. Cree un programa que cuente el mimero de ocurrencias de una palabra en 
concreto en un fichero (use el operador == de la clase string para encontrar 
la palabra) 

5. Cambie Fillvector . cpp para que imprima las lineas al reves (de la ultima 
a la primera). 

6. Cambie Fillvector . cpp para que concatene todos los elementos de la clase 
vector en un linico string antes de imprimirlo, pero no anada numeracion 
de lineas 

7. Muestre un fichero linea a linea, esperando que el usuario pulse Enter despues 
de cada linea. 

8. Cree un vector<float> e introduzca en el 25 numeros en punto flotante 
usando un bucle for. Muestre el vector. 

6 Si esta especialmente interesado en ver todas las cosas que se pueden hacer con los compo- 
nentes de la Libreria Estandar, vea el Volumen 2 de este libro en www.BruceEckel.com y tambien en 
www.dinkumware.com 
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2.9. Ejercicios 


9. Cree tres objetos vector<f loat> y rellene los dos primeros como en el ejer- 
cicio anterior. Escriba un bucle for que sume los elementos correspondientes 
y los anada al tercer vector. Muestre los tres vectores. 

10. Cree un vector<f loat> e introduzca 25 numeros en el como en el ejercicio 
anterior. Eleve cada numero al cuadrado y ponga su resultado en la misma 
posicion del vector. Muestre el vector antes y despues de la multiplication. 
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3: C en C++ 

Como C++ esta basado en C, deberfa estar familiarizado con la 
sintaxis de C para poder programar en C++, del mismo modo que de- 
berfa tener una fluidez razonable en algebra para poder hacer calcu- 
los. 

Si nunca antes ha visto C, este capitulo le dara una buena base sobre el estilo de C 
usado en C++. Si esta familiarizado con el estilo de C descrito en la primera edicion 
de Kernighan & Ritchie (tambien llamado K&R) encontrara algunas caracteristicas 
nuevas o diferentes tan to en C++ como en el estandar C. Si esta familiarizado con 
el estandar C deberia echar un vistazo al capitulo en busca de las caracteristicas 
particulares de C++. Note que hay algunas caracteristicas fundamentales de C++ 
que se introducen aqui, que son ideas basicas parecidas a caracteristicas de C o a 
menudo modificaciones en el modo en que C hace las cosas. Las caracteristicas mas 
sofisticadas de C++ se explicaran en capitulos posteriores 

Este capitulo trata por encima las construcciones de C e introduce algunas cons- 
trucciones basicas de C++, suponiendo que tiene alguna experiencia programando 
en otro lenguaje. En el CD-ROM que acompana a este libro hay una introduccion 
mas suave a C, titulada Thinking in C: Foundations for Java & C++ de Chuck Alison 
(publicada por Mid View, Inc. y disponible tambien en www.MindView.net). Se trata 
de un seminario en CD-ROM cuyo objetivo es guiarle cuidadosamente a traves de 
los fundamentos del lenguaje C. Se concentra en el conceptos necesarios para permi- 
tirle pasarse a C++ o a Java, en lugar de intentar convertirle en un experto en todos 
los oscuros recovecos de C (una de las razones para usar un lenguaje de alto nivel 
como C++ o Java es precisamente evitar muchos de estos recovecos). Tambien con- 
tiene ejercicios y soluciones guiadas. Tenga presente que este capitulo va despues 
del CD Thinking in C, el CD no reemplaza a este capitulo, sino que deberia tomarse 
como una preparacion para este capitulo y para el libro. 


3.1. Creacion de funciones 

En el antiguo C (previo al estandar), se podia invocar una funcion con cualquier 
numero y tipo de argumentos sin que el compilador se quejase. Todo parecia ir bien 
hasta que ejecutabas el programa. El programa acababa con resultados misteriosos 
(o peor, el programa fallaba) sin ninguna pista del motivo. La falta de ayuda acerca 
del paso de argumentos y los enigmaticos bugs que resultaban es, probablemente, la 
causa de que C se considerase «un lenguaje ensamblador de alto nivel». Los progra- 
madores de pre-Estandar C simplemente se adaptaron. 

C y C++ Estandar usan una caracteristica llamada prototipado de funciones. Con es¬ 
ta herramienta se han de describir los tipos de argumentos al declarar y definir una 


63 


©- 


0 


0 


0 











Volumenl" — 2012/1/12 — 13:52 — page 64 — #102 


Capitulo 3. C en C++ 


funcion. Esta description es el «prototipo». Cuando la funcion es llamada, el compi- 
lador usa el prototipo para asegurar que los argumentos pasados son los apropiados, 
y que el valor retornado es tratado correctamente. Si el programador comete un error 
al llamar a la funcion, el compilador detecta el error. 

Esencialmente, aprendio sobre prototipado de funciones (sin llamarlas de ese mo- 
do) en el capitulo previo, ya que la forma de declararlas en C++ requiere de un pro¬ 
totipado apropiado. En un prototipo de funcion, la lista de argumentos contiene los 
tipos de argumentos que se deben pasar a la funcion y (opcionalmente para la de¬ 
claration), identificadores para los argumentos. El orden y tipo de los argumentos 
debe coincidir en la declaration, definition y llamada a la funcion. A continuation 
se muestra un ejemplo de un prototipo de funcion en una declaration: 

int translate (float x, float y, float z) ; 


No se puede usar la misma sintaxis para declarar los argumentos en el prototipo 
de una funcion que en las definiciones ordinarias de variables. Esto significa que no 
se puede escribir: float x, y, z . Se debe indicar el tipo de cada argumento. En 
una declaration de funcion, lo siguiente tambien es correcto: 

int translate (float, float, float); 


Ya que el compilador no hace mas que chequear los tipos cuando se invoca la fun¬ 
cion, los identificadores se incluyen solamente para mejorar la claridad del codigo 
cuando alguien lo esta leyendo. 

En la definition de la funcion, los nombres son necesarios ya que los argumentos 
son referenciados dentro de la funcion: 

int translate (float x, float y, float z) { 
x = y = z; 

II... 

} 


Esta regia solo se aplica a C. En C++, un argumento puede no tener nombrado en 
la lista de argumentos de la definition de la funcion. Como no tiene nombre, no se 
puede utilizar en el cuerpo de la funcion, por supuesto. Los argumentos sin nombre 
se permiten para dar al programador una manera de «reservar espacio en la lista de 
argumentos». De cualquier modo, la persona que crea la funcion aun asi debe lla¬ 
mar a la funcion con los parametros apropiados. Sin embargo, la persona que crea 
la funcion puede utilizar el argumento en el futuro sin forzar una modification en el 
codigo que llama a la funcion. Esta option de ignorar un argumento en la lista tam¬ 
bien es posible si se indica el nombre, pero siempre apareceria un molesto mensaje 
de advertencia, informando que el valor no se utiliza, cada vez que se compila la 
funcion. La advertencia desaparece si se quita el nombre del argumento. 

C y C++ tienen otras dos maneras de declarar una lista de argumentos. Si se tie¬ 
ne una lista de argumentos vacia, se puede declarar esta como func () en C++, lo 
que indica al compilador que hay exactamente cero argumentos. Hay que tener en 
cuenta que esto solo significa una lista de argumentos vacia en C++. En C significa 
«un numero indeterminado de argumentos» (lo que es un «agujero» en C ya que 
deshabilita la comprobacion de tipos en ese caso). En ambos, C y C++, la declara¬ 
tion func (void) ; significa una lista de argumentos vacia. La palabra clave void 
significa «nada» en este caso (tambien puede significar «sin tipo» en el caso de los 
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punteros, como se vera mas adelante en este capitulo). 

La otra opcion para las listas de argumentos se produce cuando no se sabe cuan- 
tos argumentos o que tipos tendran los argumentos; esto se conoce como lista de 
argumentos variable. Esta «lista incierta de argumentos» se representada con puntos 
suspensivos (...). Definir una funcion con una lista de argumentos variable es signifi- 
cativamente mas complicado que definir una funcion normal. Se puede utilizar una 
lista de argumentos variable para una funcion que tiene un grupo de argumentos 
fijos si (por alguna razon) se quiere deshabilitar la comprobacion del prototipo de 
funcion. Por eso, se debe restringir el uso de listas de argumentos variables en C y 
evitarlas en C++ (en el cual, como aprendera, hay alternativas mucho mejores). El 
manejo de listas de argumentos variables se describe en la seccion de librerias de la 
documentacion de su entorno C particular. 


3.1.1. Valores de retorno de las funciones 

Un prototipo de funcion C++ debe especificar el tipo de valor devuelto de la fun¬ 
cion (en C, si no se especifica sera por defecto un inf). La especificacion del tipo de 
retorno precede al nombre de la funcion. Para especificar que no se devolvera valor 
alguno, se utiliza la palabra reservada void. Esto provocara un error si se intenta de- 
volver un valor desde la funcion. A continuacion hay algunos prototipos completos 
de funciones: 

int f1(void); // Devuelve un entero, no tiene argumentos 
int f 2 (); // igual que fl() en C++ pero no en C Stantard 
float f3 (float, int, char, double); // Devuelve un float 
void f4(void); // No toma argumentos, no devuelve nada 


Para devolver un valor desde una funcion, se utiliza la sentencia return. Esta 
sentencia termina la funcion y salta hasta la sentencia que se halla justo despues 
de la llamada a la funcion. Si return tiene un argumento, se convierte en el valor 
de retorno de la funcion. Si una funcion indica que retornara un tipo en particular, 
entonces cada sentencia return debe retornar un valor de ese tipo. Puede haber 
mas de una sentencia return en una definicion de funcion: 

//: C03:Return.cpp 
// Use of "return" 

#include <iostream> 

using namespace std; 

char cfunc(int i) { 
if(1 == 0) 

return 'a'; 
if(1 == 1) 
return 'g'; 
if(i == 5) 

return 'z'; 
return 'c'; 


int main () { 

cout << "type an integer: " 
int val; 
cin >> val; 

cout << cfunc(val) << endl; 
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} ///:~ 


En cfunc (), el primer if que comprueba que la condition sea true sale de 
la funcion con la sentencia return. Fijese que la declaration de la funcion no es 
necesaria puesto que la definicion aparece antes de ser utilizada en main (), de modo 
que el compilador sabe de su existencia desde dicha definicion. 


3.1.2. Uso de funciones de librerias C 

Todas las funciones en la libreria local de funciones de C estan disponibles cuan- 
do se programa en C++. Se deberia buscar bien en la libreria de funciones antes de 
definir una propia - hay muchas probabilidades de que alguien haya resuelto el pro- 
blema antes, y probablemente haya dedicado mas tiempo pensando y depurando. 

Una advertencia, del mismo modo: muchos compiladores incluyen muchas fun¬ 
ciones extra que hacen la vida mucho mas facil y resultan tentadoras, pero no son 
parte de la Libreria C Estandar. Si esta seguro de que jamas deseara portar la aplica- 
cion a otra plataforma (yy quien esta seguro de eso?), adelante -utilice esas funciones 
y haga su vida mas facil. Si desea que la aplicacion pueda ser portada, deberia cenirse 
unicamente al uso de funciones de la Libreria Estandar. Si debe realizar actividades 
especificas de la plataforma, deberia intentar aislar este codigo de tal modo que pue¬ 
da cambiarse facilmente al migrarlo a otra plataforma. En C++, las actividades de 
una plataforma especifica a menudo se encapsulan en una clase, que es la solution 
ideal. 

La formula para usar una libreria de funciones es la siguiente: primero, encontrar 
la funcion en la referenda de programacion (muchas referencias de programacion 
ordenan las funciones por categoria ademas de alfabeticamente). La description de 
la funcion deberia incluir una section que demuestre la sintaxis del codigo. La parte 
superior de esta section tiene al menos una linea #include, mostrando el fichero 
principal que contiene el prototipo de funcion. Debe copiar este # include en su 
fichero para que la funcion este correctamente declarada. Ahora puede llamar la 
funcion de la misma manera que aparece en la section de sintaxis. Si comete un error, 
el compilador lo descubrira comparando la llamada a la funcion con el prototipo de 
la cabecera e informara de dicho error. El enlazador busca en la Libreria Estandar por 
defecto, de modo que lo unico que hay que hacer es: incluir el fichero de cabecera y 
llamar a la funcion. 


3.1.3. Creadon de librerias propias 

Puede reunir funciones propias juntas en una libreria. La mayoria de paquetes 
de programacion vienen con un FIXME:bibliotecario que maneja grupos de modulos 
objeto. Cada FIXME:bibliotecario tiene sus propios comandos, pero la idea general 
es la siguiente: si se desea crear una libreria, se debe hacer un fichero cabecera que 
contenga prototipos de todas las funciones de la libreria. Hay que ubicar este fichero 
de cabecera en alguna parte de la ruta de busqueda del preprocesador, ya sea en el 
directorio local (de modo que se podra encontrar mediante #include "header") 
o bien en el directorio include (por lo que se podra encontrar mediante # inc¬ 
lude <header>). Luego se han de juntar todos los modulos objeto y pasarlos al 
FIXME:bibliotecario junto con un nombre para la libreria recien construida (la ma¬ 
yoria de los bibliotecarios requieren una extension comun, como por ejemplo . lib 
o . a). Se ha de ubicar la libreria completa donde residan todas las demas, de ma- 
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nera que el enlazador sabra buscar esas funciones en dicha libreria al ser invocadas. 
Pueden encontrar todos los detalles en su documentation particular, ya que pueden 
variar de un sistema a otro. 


3.2. Control de flujo 

Esta seccion cubre las sentencias de control de flujo en C++. Debe familiarizarse 
con estas sentencias antes de que pueda leer o escribir codigo C o C++. 

C++ usa todas las sentencias de control de ejecucion de C. Esto incluye if-else, 
do-while, for, y una sentencia de seleccion llamada switch. C++ tambien admite 
el infame goto, el cual sera evitado en este libro. 


3.2.1. Verdadero y falso 

Todas las sentencias condicionales utilizan la veracidad o la falsedad de una ex¬ 
presion condicional para determinar el camino de ejecucion. Un ejemplo de expre¬ 
sion condicional es A == B. Esto utiliza el operador condicional == para saber si la 
variable A es equivalente a la variable B. La expresion produce un booleano true o 
false (estas son palabras reservadas solo en C++; en C una expresion es verdade- 
ra(frae) si se evalua con un valor diferente de cero). Otros operadores condicionales 
son >, <, >=, etc. Las sentencias condicional se trataran a fondo mas adelante en este 
capitulo. 


3.2.2. if-else 

La sentencia if-else puede existir de dos formas: con o sin el else. Las dos 
formas son: 

if (oexpresin) 
sentencia 


6 


if (oexpresin) 
sentencia 

else 

sentencia 


La «expresion» se evalua como true o false. La «sentencia» puede ser una 
simple acabada en un punto y coma, o bien una compuesta, lo que no es mas que un 
grupo de sentencias simples encerradas entre Haves. Siempre que se utiliza la palabra 
«sentencia», implica que la sentencia es simple o compuesta. Tenga en cuenta que 
dicha sentencia puede ser incluso otro i f , de modo que se pueden anidar. 

//: C03:Ifthen.cpp 

// Demonstration of if and if-else conditionals 

#include <iostream> 

using namespace std; 


int main() { 
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int i; 

cout << "type a number and 'Enter'" << endl; 
cin >> i; 
if (i > 5) 

cout << "It's greater than 5" << endl; 

else 

if (i < 5) 

cout << "It's less than 5 " << endl; 

else 

cout << "It's equal to 5 " << endl; 

cout << "type a number and 'Enter'" << endl; 
cin >> i; 
if ( i < 10) 

if(i > 5) // "if" is just another statement 

cout << "5 < i < 10" << endl; 

else 

cout << "i <= 5" << endl; 
else // Matches "if (i < 10)" 
cout << "i >= 10" << endl; 

} // / : ~ 


Por convenio se indenta el cuerpo de una sentencia de control de flujo, de modo 
que el lector puede determinar facilmente donde comienza y donde acaba 1 . 


3.2.3. while 

En los bucles de control while, do-while, y for, una sentencia se repite hasta 
que la expresion de control sea false. La estructura de un bucle while es: 

while(oexpresin) sentencia 


La expresion se evalua una vez al comienzo del bucle y cada vez antes de cada 
iteracion de la sentencia. 

Este ejemplo se mantiene en el cuerpo del bucle while hasta que introduzca el 
numero secreto o presione Control-C. 

//: C03:Guess.cpp 

// Guess a number (demonstrates "while") 

#include <iostream> 

using namespace std; 

int main() { 

int secret = 15; 
int guess = 0; 

// "!=" is the "not-equal" conditional: 
while (guess != secret) { // Compound statement 
cout << "guess the number: "; 
cin >> guess; 

1 Fijese en que todas las convenciones parecen acabar estando de acuerdo en que hay que hacer algun 
tipo de indentation. La pelea entre los estilos de formateo de codigo no tiene fin. En el Apendice A se 
explica el estilo de codification que se usa en este libro. 
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} 

cout << "You guessed it!" << endl; 
} ///:~ 


La expresion condicional del while no esta restringida a una simple prueba co- 
mo en el ejemplo anterior; puede ser tan complicada como se desee siempre y cuando 
se produzca un resultado true o false. Tambien puede encontrar codigo en el que 
el bucle no tiene cuerpo, solo un simple punto y coma: 

while (/* hacer muchas cosas */) 


En estos casos, el programador ha escrito la expresion condicional no solo para 
realizar la evaluation, sino tambien para hacer el trabajo. 


3.2.4. do-while 


El aspecto de do-while es 


do 

sentencia 
while(oexpresin); 


El do-while es diferente del while ya que la sentencia siempre se ejecuta al 
menos una vez, aun si la expresion resulta false la primera vez. En un while 
normal, si la condition es falsa la primera vez, la sentencia no se ejecuta nunca. 

Si se utiliza un do-while en Guess. cpp, la variable guess no necesitaria un 
valor ficticio inicial, ya que se inicializa por la sentencia cin antes de que la variable 
sea evaluada: 

//: C03:Guess2.cpp 

// The guess program using do-while 

#include <iostream> 

using namespace std; 

int main() { 

int secret = 15; 

int guess; // No initialization needed here 

do { 

cout << "guess the number: "; 
cin >> guess; // Initialization happens 
} while (guess != secret); 
cout << "You got it!" << endl; 

} ///:- 


Por alguna razon, la mayoria de los programadores tienden a evitar el do-while 
y se limitan a trabajar con while. 
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3.2.5. for 

Un bucle for realiza una initialization antes de la primera iteracion. Luego eje- 
cuta una evaluation conditional y, al final de cada iteration, efectua algun tipo de 
«siguiente paso». La estructura del bucle f or es: 

for(oinitializacin; ocondicin; paso) 
sentencia 


Cualquiera de las expresiones de «inicializadon», «condicion», o «paso» pueden 
estar vacias. El codigo de «inicializacion» se ejecuta una unica vez al principio. La ex- 
presion «condicional» se evalua antes de cada iteracion (si se evalua a false desde 
el principio, el cuerpo del bucle nunca llega a ejecutarse). Al final de cada iteracion 
del bucle, se ejecuta «paso». 

Los bucles f or se utilizan generalmente para tareas de «conteo»: 

//: C03:Charlist.cpp 

// Display all the ASCII characters 

// Demonstrates "for" 

#include <iostream> 

using namespace std; 

int main () { 

for(int i = 0; i < 128; i=i+l) 

if (i != 26) // ANSI Terminal Clear screen 

cout << " value: " << i 
<< " character: " 

<< char(i) // Type conversion 
<< endl; 

} ///:- 


Puede ocurrir que la variable i sea definida en el punto en el que se utiliza, en 
vez de al principio del bloque delimitado por la apertura de la Have j. Esto difiere de 
los lenguajes procedurales tradicionales (incluyendo C), en los que se requiere que 
todas las variables se definan al principio del bloque. Esto se discutira mas adelante 
en este capitulo. 


3.2.6. Las palabras reservadas break y continue 

Dentro del cuerpo de cualquiera de las estructuras de bucle while, do-while, 
o for, se puede controlar el flujo del bucle utilizando break y continue, break 
interrumpe el bucle sin ejecutar el resto de las sentencias de esa iteracion. continue 
detiene la execution de la iteracion actual, vuelve al principio del bucle y comienza 
la siguiente iteracion. 

A modo de ejemplo de break y continue, esteprogramaes unmenu de sistema 
muy simple: 

//: C03:Menu.cpp 

// Simple menu program demonstrating 
// the use of "break" and "continue" 

#include <iostream> 

using namespace std; 
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int main () { 

char c; //To hold response 

while(true) { 

cout « "MAIN MENU:" << endl; 

cout << "1: left, r: right, q: quit -> " 

cin >> c; 

if (c == 'q') 

break; // Out of "while(1)" 
if (c == '1' ) { 

cout « "LEFT MENU:" << endl; 
cout << "select a or b: "; 
cin >> c; 
if (c == 'a' ) { 

cout << "you chose 'a'" << endl; 
continue; // Back to main menu 

} 

if (c == 'b') { 

cout << "you chose 'b'" << endl; 
continue; // Back to main menu 


else { 

cout << "you didn't choose a or b!" 
<< endl; 

continue; // Back to main menu 


if (c == 'r') { 

cout « "RIGHT MENU:" « endl; 
cout << "select c or d: "; 
cin >> c; 
if (c == 'c' ) { 

cout << "you chose 'c'" << endl; 

continue; // Back to main menu 

} 

if (c == 'd') { 

cout << "you chose 'd'" << endl; 

continue; // Back to main menu 


else { 

cout << "you didn't choose c or d!" 
<< endl; 

continue; // Back to main menu 


cout << "you must type 1 or r or q!" << endl; 

} 

cout << "quitting menu..." << endl; 

} ///:- 


Si el usuario selecciona q en el menu principal, se utiliza la palabra reservada b- 
reak para salir, de otro modo, el programa continua ejecutandose indefinidamente. 
Despues de cada seleccion de sub-menu, se usa la palabra reservada continue para 
volver atras hasta el comienzo del bucle while. 

La sentencia while (true) es el equivalente a decir «haz este bucle para siem- 
pre». La sentencia break permite romper este bucle infinito cuando el usuario teclea 
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Una sentencia switch selecciona un fragmento de codigo entre varios posibles 
en base al valor de una expresion entera. Su estructura es: 

switch(selector) { 

case valor-enterol : sentencia; break; 

case valor-entero2 : sentencia; break; 

case valor-entero3 : sentencia; break; 

case valor-entero4 : sentencia; break; 

case valor-entero5 : sentencia; break; 

(...) 

default; sentencia; 

} 

selector es una expresion que produce un valor entero. El switch compara 
el resultado de selector para cada valor entero. Si encuentra una coincidencia, se 
ejecutara la sentencia correspondiente (sea simple o compuesta). Si no se encuentra 
ninguna coincidencia se ejecutara la sentencia default. 

Se puede observar en la definicion anterior que cada case acaba con un break, 
lo que causa que la ejecucion salte hasta el final del cuerpo del switch (la Have final 
que cierra el switch). Estaes la forma convencional de construir una sentencia swi¬ 
tch, pero la palabra break es opcional. Si no se indica, el case que se ha cumplido 
«cae» al siguiente de la lista. Esto significa, que el codigo del siguiente case, se 
ejecutara hasta que se encuentre un break. Aunque normalmente no se desea este 
tipo de comportamiento, puede ser de ayuda para un programador experimentado. 

La sentencia switch es una manera limpia de implementar una seleccion multi - 
modo (por ejemplo, seleccionando de entre un numero de paths de ejecucion), pero 
requiere un selector que pueda evaluarse como un entero en el momenta de la com- 
pilacion. Si quisiera utilizar, por ejemplo, un objeto string como selector, no fun- 
cionara en una sentencia switch. Para un selector de tipo string, se debe utilizar 
una serie de sentencias if y comparar el string dentro de la condicion. 

El ejemplo del menu demostrado anteriormente proporciona un ejemplo particu- 
larmente interesante de un switch: 

//: C03:Menu2.cpp 

//A menu using a switch statement 

#include <iostream> 

using namespace std; 

int main() { 

bool quit = false; // Flag for quitting 

while (quit == false) { 

cout << "Select a, b, c or q to quit: "; 
char response; 
cin >> response; 
switch (response) { 

case 'a' : cout << "you chose 'a'" << endl; 

break; 

case 'b' : cout << "you chose 'b'" << endl; 

break; 
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case 

' c' 

: cout << 

break; 

"you chose 'c'" 

<< endl; 

case 

'q' 

: cout << "quitting menu" 
quit = true; 
break; 

<< endl; 

default 

: cout << 

<< endl; 

"Please use a,b, 

c or q! " 


///:- 


El flag quit es un bool, abreviatura para «booleano», que es un tipo que solo se 
encuentra en C++. Puede tener unicamente los valores true o false. Seleccionando 
q se asigna el valor true al flag «quit». La proxima vez que el selector sea evaluado, 
quit == false retornara false de modo que el cuerpo del bucle while no se 
ejecutara. 


3.2.8. Uso y maluso de goto 

La palabra clave goto esta soportada en C++, dado que existe en C. El uso de 
goto a menudo es considerado como un estilo de programacion pobre, y la mayor 
parte de las veces lo es. Siempre que se utilice goto, se debe revisar bien el codigo 
para ver si hay alguna otra manera de hacerlo. En raras ocasiones, goto puede re¬ 
solver un problema que no puede ser resuelto de otra manera, pero, aun asi, se debe 
considerar cuidadosamente. A continuation aparece un ejemplo que puede ser un 
candidato plausible: 

//: C03:gotoKeyword.cpp 

// The infamous goto is supported in C++ 

#include <iostream> 

using namespace std; 

int main() { 

long val = 0; 

for(int i = 1; i < 1000; i++) { 

for(int j=l; j<100; j+=10) { 

val = i * j; 
if (val > 47000) 
goto bottom; 

// Break would only go to the outer 'for' 



bottom: //A label 
cout << val << endl; 
} ///:- 


La alternativa serf a dar valor a un booleano que sea evaluado en el for externo, 
y luego hacer un break desde el for interno. De todos modos, si hay demasiados 
niveles deforo while esto puede llegar a ser pesado. 
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3.2.9. Recursividad 

La recursividad es una tecnica de programacion interesante y a veces util, en 
donde se llama a la funcion desde el cuerpo de la propia funcion. Por supuesto, si 
eso es todo lo que hace, se estaria llamando a la funcion hasta que se acabase la 
memoria de ejecucion, de modo que debe existir una manera de «escaparse» de la 
llamada recursiva. En el siguiente ejemplo, esta «escapada» se consigue simplemente 
indicando que la recursion solo continuara hasta que cat exceda Z: 2 

//: C03:CatsInHats.cpp 

// Simple demonstration of recursion 

#include <iostream> 

using namespace std; 

void removeHat (char cat) { 

for(char c = 'A'; c < cat; C++) 
cout << " " ; 

if (cat <= 'Z') { 

cout << "cat " << cat << endl; 
removeHat(cat + 1); // Recursive call 
} else 

cout << "VOOM!!!" << endl; 

} 


int main () { 

removeHat ('A' ) ; 

} ///:- 


En removeHat (), se puede ver que mientras cat sea menor que Z, removeH¬ 
at () se llamara a si misma, efectuando asi la recursividad. Cada vez que se llama 
removeHat (), su argumento crece en una unidad mas que el cat actual de modo 
que el argumento continua aumentando. 

La recursividad a menudo se utiliza cuando se evalua algun tipo de problema 
arbitrariamente complejo, ya que no se restringe la solucion a ningun tamano par¬ 
ticular - la funcion puede simplemente efectuar la recursividad hasta que se haya 
alcanzado el final del problema. 


3.3. Introduction a los operadores 

Se pueden ver los operadores como un tipo especial de funcion (aprendera que en 
C++ la sobrecarga de operadores los trata precisamente de esa forma). Un opera dor 
recibe uno o mas argumentos y produce un nuevo valor. Los argumentos se pasan 
de una manera diferente que en las llamadas a funciones normales, pero el efecto es 
el mismo. 

Por su experiencia previa en programacion, debe estar razonablemente comodo 
con los operadores que se han utilizados. Los conceptos de adicion (+), substraccion 
y resta unaria (-), multiplication (*), division (/), y asignacion (=) tienen todos el 
mismo significado en cualquier lenguaje de programacion. El grupo completo de 
operadores se enumera mas adelante en este capitulo. 


2 Gracias a Kris C. Matson por proponer este ejercicio. 
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3.3.1. Precedencia 

La precedencia de operadores define el orden en el que se evalua una expresion 
con varios operadores diferentes. C y C++ tienen reglas especificas para determinar 
el orden de evaluacion. Lo mas facil de recordar es que la multiplicacion y la division 
se ejecutan antes que la suma y la resta. Luego, si una expresion no es transparente 
al programador que la escribe, probablemente tampoco lo sera para nadie que lea 
el codigo, de modo que se deben usar parentesis para hacer explicito el orden de la 
evaluacion. Por ejemplo: 

A = X + Y - 2/2 + Z; 

Tiene un significado muy distinto de la misma expresion pero con un configura¬ 
tion de parentesis particular: 

A = X + (Y - 2) / (2 + Z) ; 

(Intente evaluar el resultado con X =1, Y = 2, y Z = 3.) 



3.3.2. Auto incremento y decremento 

C, y por tanto C++, esta lleno de atajos. Los atajos pueden hacer el codigo mucho 
mas facil de escribir, y a veces mas dificil de leer. Quizas los disenadores del lenguaje 
C pensaron que seria mas facil entender un trozo de codigo complicado si los ojos 
no tienen que leer una larga lrnea de letras. 

Los operadores de auto-incremento y auto-decremento son de los mejores atajos. 
Se utilizan a menudo para modificar las variables que controlan el numero de veces 
que se ejecuta un bucle. 

El operador de auto-decremento es — que significa «decrementar de a una uni- 
dad». El operador de auto-incremento es ++ que significa «incrementar de a una 
unidad». Si es un entero, por ejemplo, la expresion ++A es equivalente a (A = A + 
1). Los operadores de auto-incremento y auto-decremento producen el valor de la 
variable como resultado. Si el operador aparece antes de la variable (p.ej, ++A), la 
operacion se ejecuta primero y despues se produce el valor resultante. Si el operador 
aparece a continuation de la variable (p.ej, A++), primero se produce el valor actual, 
y luego se realiza la operacion. Por ejemplo: 

//; C03:Autoincrement.cpp 
// Shows use of auto-increment 
// and auto-decrement operators. 

#include <iostream> 

using namespace std; 

int main() { 

int i = 0; 
int j = 0; 

cout << ++i << endl; // Pre-increment 

cout << j++ << endl; // Post-increment 

cout << —i << endl; // Pre-decrement 

cout << j— << endl; // Post decrement 

} ///:~ 
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Si se ha estado preguntando acerca del nombre «C++», ahora lo entendera. Sig- 
nifica «un paso mas alia de C» 3 


3.4. Introduction a los tipos de datos 

Los tipos de datos definen el modo en que se usa el espacio (memoria) en los pro- 
gramas. Especificando un tipo de datos, esta indicando al compilador como crear un 
espacio de almacenamiento en particular, y tambien como manipular este espacio. 

Los tipos de datos pueden estar predefinidos o abstractos. Un tipo de dato prede- 
finido es intrinsecamente comprendido por el compilador. Estos tipos de datos son 
casi identicos en C y C++. En contraste, un tipo de datos definido por el usuario es 
aquel que usted o cualquier otro programador crea como una clase. Estos se denomi- 
nan comunmente tipos de datos abstractos. El compilador sabe como manejar tipos 
predefinidos por si mismo; y «aprende» como manejar tipos de datos abstractos le- 
yendo los ficheros de cabeceras que contienen las declaraciones de las clases (esto se 
vera con mas detalle en los siguientes capitulos). 


3.4.1. Tipos predefinidos basicos 

La especificacion del Estandar C para los tipos predefinidos (que hereda C++) 
no indica cuantos bits debe contener cada uno de ellos. En vez de eso, estipula el 
minimo y maximo valor que cada tipo es capaz de almacenar. Cuando una maquina 
se basa en sistema binario, este valor maximo puede ser directamente traducido a 
un numero minimo necesario de bits para alojar ese valor. De todos modos, si una 
maquina usa, por ejemplo, el codigo binario decimal (BCD) para representar los nu- 
meros, entonces el espacio requerido para alojar el maximo numero para cada tipo 
de datos sera diferente. El minimo y maximo valor que se puede almacenar en los 
distintos tipos de datos se define en los ficheros de cabeceras del sistema limits . h 
y float . h (en C++ normalmente sera #include <climits> y <cfloat>). 

C y C++ tienen cuatro tipos predefinidos basicos, descritos aqui para maquinas 
basadas en sistema binario. Un char es para almacenar caracteres y utiliza un minimo 
de 8 bits (un byte) de espacio, aunque puede ser mas largo. Un int almacena un 
numero entero y utiliza un minimo de dos bytes de espacio. Los tipos float y el 
double almacenan numeros con coma flotante, usualmente en formato IEEE, el float 
es para precision simple y el double es para doble precision. 

Como se ha mencionado previamente, se pueden definir variables en cualquier 
sitio en un ambito determinado, y puede definirlas e inicializarlas al mismo tiempo. 
A continuacion se indica como definir variables utilizando los cuatro tipos basicos 
de datos: 

//: C03:Basic.cpp 

// Defining the four basic data 

// types in C and C++ 

int main() { 

// Definition without initialization: 

char protein; 

int carbohydrates; 

float fiber; 

3 (N. de T.) ...aunque se evalua como «C». 
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double fat; 

// Simultaneous definition & initialization: 

char pizza = 'A', pop = ' Z'; 
int dongdings = 100, twinkles = 150, 
heehos = 200; 

float chocolate = 3.14159; 

// Exponential notation: 
double fudge_ripple = 6e-4; 

} ///:- 


La primera parte del programa define variables de los cuatro tipos basicos sin 
inicializarlas. Si no se inicializa una variable, el Estandar dice que su contenido es 
indefinido (normalmente, esto significa que contienen basura). La segunda parte del 
programa define e inicializa variables al mismo tiempo (siempre es mejor, si es posi- 
ble, dar un valor inicial en el momento de la definicion). Note que el uso de notacion 
exponencial en la contante 6e-4, significa «6 por 10 elevado a -4». 


3.4.2. booleano, verdadero y falso 

Antes de que bool se convirtiese en parte del Estandar C++, todos tendian a uti- 
lizar diferentes tecnicas para producir comportamientos similares a los booleanos. 
Esto produjo problemas de portabilidad y podian acarrear errores sutiles. 

El tipo bool del Estandar C++ puede tener dos estados expresados por las cons- 
tantes predefinidas true (lo que lo convierte en el entero 1) y false (lo que lo con- 
vierte en el entero 0). Estos tres nombres son palabras reservadas. Ademas, algunos 
elementos del lenguaje han sido adaptados: 


Elemento 

Uso con booleanos 

&& 1 1 ! 

Toman argumentos booleanos y 
producen valores bool 

<><=>= == != 

Producen resultados bool 

if, for, while, do 

Las expresiones condicionales se 
convierten en valores bool 

?■ 

El primer operando se convierte a un 
valor bool 


Cuadro 3.1: Expresiones que utilizan booleanos 


Como hay mucho codigo existente que utiliza un int para representar una bande- 
ra, el compilador lo convertira implicitamente de int a bool (los valores diferentes de 
cero produciran true, mientras que los valores cero, produciran false). Idealmen- 
te, el compilador le dara un aviso como una sugerencia para corregir la situacion. 

Un modismo que se considera «estilo de programacion pobre» es el uso de ++ 
para asignar a una bandera el valor true. Esto aun se permite, pero esta obsoleto, 
lo que implica que en el futuro sera ilegal. El problema es que se esta haciendo una 
conversion implicita de un bool a un int, incrementando el valor (quiza mas alia del 
rango de valores booleanos cero y uno), y luego implicitamente convirtiendolo otra 
vez a bool. 

Los punteros (que se describen mas adelante en este capitulo) tambien se con- 
vierten automaticamente a bool cuando es necesario. 
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3.4.3. Especificadores 

Los especificadores modifican el significado de los tipos predefinidos basicos y 
los expanden a un conjunto mas grande. Hay cuatro especificadores: long, short, 
signed y unsigned. 

long y short modifican los valores maximos y minimos que un tipo de datos 
puede almacenar. Un inf piano debe tener al menos el tamano de un short. La je- 
rarquia de tamanos para tipos enteros es: short inf, inf, long inf. Todos pueden ser 
del mismo tamano, siempre y cuando satisfagan los requisitos de minimo/maximo. 
En una maquina con una palabra de 64 bits, por defecto, todos los tipos de datos 
podrian ser de 64 bits. 

La jerarquia de tamano para los numeros en coma flotante es: float, double y 
long double. «long float» no es un tipo valido. No hay numeros en coma flotantes de 
tamano short. 

Los especificadores signed y unsigned indican al compilador como utilizar el 
bit del signo con los tipos enteros y los caracteres (los numeros de coma flotante 
siempre contienen un signo). Un numero unsigned no guarda el valor del signo 
y por eso tiene un bit extra disponible, de modo que puede guardar el doble de 
numeros positivos que pueden guardarse en un numero signed, signed se supone 
por defecto y solo es necesario con char, char puede ser o no por defecto un signed. 
Especificando signed char, se esta forzando el uso del bit del signo. 

El siguiente ejemplo muestra el tamano de los tipos de datos en bytes utilizando 
el operador sizeof, descripto mas adelante en ese capitulo: 

//: C03:Specify.cpp 

// Demonstrates the use of specifiers 

#include <iostream> 

using namespace std; 

int main() { 

char c; 

unsigned char cu; 
int i; 

unsigned int iu; 
short int is; 

short iis; // Same as short int 

unsigned short int isu; 
unsigned short iisu; 
long int il; 

long iil; // Same as long int 

unsigned long int ilu; 

unsigned long iilu; 

float f; 

double d; 

long double Id; 

cout 

<< "\n char= " << sizeof (c) 

<< "\n unsigned char = " << sizeof (cu) 

<< "\n int = " << sizeof (i) 

<< "\n unsigned int = " << sizeof (iu) 

<< "\n short = " << sizeof (is) 

<< "\n unsigned short = " << sizeof (isu) 

<< "\n long = " << sizeof (il) 

<< "\n unsigned long = " << sizeof (ilu) 
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<< "\n float = " << sizeof(f) 

<< "\n double = " << sizeof (d) 

<< "\n long double = " << sizeof (Id) 
<< endl; 

) ///:- 


Tenga en cuenta que es probable que los resultados que se consiguen ejecutan- 
do este programa sean diferentes de una maquina/sistema operativo/compilador a 
otro, ya que (como se mencionaba anteriormente) lo unico que ha de ser consistente 
es que cada tipo diferente almacene los valores minimos y maximos especificados en 
el Estandar. 

Cuando se modifica un int con short o long, la palabra reservada int es opcio- 
nal, como se muestra a continuation. 


3.4.4. Introduccion a punteros 

Siempre que se ejecuta un programa, se carga primero (tipicamente desde dis¬ 
co) a la memoria del ordenador. De este modo, todos los elementos del programa se 
ubican en algun lugar de la memoria. La memoria se representa normalmente como 
series secuenciales de posiciones de memoria; normalmente se hace referenda a es- 
tas localizaciones como bytes de ocho bits, pero realmente el tamaho de cada espacio 
depende de la arquitectura de cada maquina particular y se llamada normalmente 
tamaho de palabra de la maquina. Cada espacio se puede distinguir univocamen- 
te de todos los demas espacios por su direction. Para este tema en particular, se 
establecera que todas las maquinas usan bytes que tienen direcciones secuenciales, 
comenzando en cero y subiendo hasta la cantidad de memoria que posea la maquina. 

Como el programa reside en memoria mientras se esta ejecutando, cada elemento 
de dicho programa tiene una direction. Suponga que empezamos con un programa 
simple: 

//: C03:YourPetsl.cpp 

#include <iostream> 

using namespace std; 

int dog, cat, bird, fish; 

void f (int pet) { 

cout << "pet id number: " << pet << endl; 

} 

int main() { 

int i, j, k; 

1 ///:~ 


Cada uno de los elementos de este programa tiene una localization en memoria 
mientras el programa se esta ejecutando. Incluso las funciones ocupan espacio. Co¬ 
mo vera, se da por sentado que el tipo de un elemento y la forma en que se define 
determina normalmente el area de memoria en la que se ubica dicho elemento. 

Hay un operador en C y C++ que permite averiguar la direction de un elemento. 
Se trata del operador &. Solo hay que anteponer el operador & delante del nom- 
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bre identificador y obtendra la direccion de ese identificador. Se puede modificar 
YourPetsl. cpp para mostrar las direcciones de todos sus elementos, del siguiente 
modo: 

//: C03:YourPets2.cpp 

#include <iostream> 

using namespace std; 

int dog, cat, bird, fish; 

void f (int pet) { 

cout << "pet id number: " << pet << endl; 

} 


int main () { 


int 

if j 

, k; 



cout 

<< 

" f () : 

II 

<< (long) &f << endl; 

cout 

<< 

"dog: 

II 

<< (long) &dog << endl; 

cout 

<< 

" cat: 

II 

<< (long) Scat << endl; 

cout 

<< 

"bird 

II 

<< (long) &bird << endl 

cout 

<< 

"fish 

II 

<< (long) Sfish << endl 

cout 

<< 

II -j- . II 

<< 

(long)&i << endl; 

cout 

<< 

II j . II 

<< 

(long)&j << endl; 

cout 

} ///: 

<< 

"k: " 

<< 

(long) &k << endl; 


El (long) es una molde. Indica «No tratar como su tipo normal, sino como un 
long». El molde no es esencial, pero si no existiese, las direcciones aparecerian en 
hexadecimal, de modo que el moldeado a long hace las cosas mas legibles. 

Los resultados de este programa variaran dependiendo del computador, del sis- 
tema operativo, y de muchos otros tipos de factores, pero siempre daran un resulta- 
do interesante. Para una unica ejecucion en mi computador, los resultados son como 
estos: 

f () : 4198736 
dog: 4323632 
cat: 4323636 
bird: 4323640 
fish: 4323644 
i: 6684160 
j: 6684156 
k: 6684152 

Se puede apreciar como las variables que se han definido dentro de main () estan 
en un area distinta que las variables definidas fuera de main (); entendera el porque 
cuando se profundice mas en el lenguaje. Tambien, f () parece estar en su propia 
area; el codigo normalmente se separa del resto de los datos en memoria. 

Otra cosa a tener en cuenta es que las variables definidas una a continuation de 
la otra parecen estar ubicadas de manera contigua en memoria. Estan separadas por 
el numero de bytes requeridos por su tipo de dato. En este programa el unico tipo 
de dato utilizado es el int, y la variable cat esta separada de dog por cuatro bytes, 
bird esta separada por cuatro bytes de cat, etc. De modo que en el computador en 
que ha sido ejecutado el programa, un entero ocupa cuatro bytes. 
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^Que se puede hacer con las direcciones de memoria, ademas de este interesante 
experimento de mostrar cuanta memoria ocupan? Lo mas importante que se puede 
hacer es guardar esas direcciones dentro de otras variables para su uso posterior. C 
y C++ tienen un tipo de variable especial para guardar una direccion. Esas variables 
se llaman punteros. 

El operador que define un puntero es el mismo que se utiliza para la multiplica- 
cion: *. El compilador sabe que no es una multiplicacion por el contexto en el que se 
usa, tal como podra comprobar. 

Cuando se define un puntero, se debe especificar el tipo de variable al que apun- 
ta. Se comienza dando el nombre de dicho tipo, despues en lugar de escribir un 
identificador para la variable, usted dice «Espera, esto es un puntero» insertando un 
asterisco entre el tipo y el identificador. De modo que un puntero a int tiene este 
aspecto: 

int* ip; // ip apunta a una variable int 

La asociacion del * con el tipo parece practica y legible, pero puede ser un poco 
confusa. La tendencia podria ser decir «puntero-entero» como un si fuese un tipo 
simple. Sin embargo, con un int u otro tipo de datos basico, se puede decir: 

int a, b, c; 

asi que con un puntero, diria: 

int* ipa, ipb, ipc; 

La sintaxis de C (y por herencia, la de C++) no permite expresiones tan comodas. 
En las definiciones anteriores, solo ipa es un puntero, pero ipb e ipc son ints nor- 
males (se puede decir que «* esta mas unido al identificador»). Como consecuencia, 
los mejores resultados se pueden obtener utilizando solo una definicion por linea; y 
aun se conserva una sintaxis comoda y sin la confusion: 

int* ipa; 
int* ipb; 
int* ipc; 

Ya que una pauta de programacion de C++ es que siempre se debe inicializar una 
variable al definirla, realmente este modo funciona mejor. Por ejemplo. Las variables 
anteriores no se inicializan con ningun valor en particular; contienen basura. Es mas 
facil decir algo como: 

int a = 47; 
int* ipa = &a; 

Ahora tanto a como ipa estan inicializadas, y ipa contiene la direccion de a. 

Una vez que se inicializa un puntero, lo mas basico que se puede hacer con El es 
utilizarlo para modificar el valor de lo que apunta. Para acceder a la variable a traves 
del puntero, se dereferencia el puntero utilizando el mismo operador que se uso para 
definirlo, como sigue: 
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*ipa = 100; 

Ahora a contiene el valor 100 en vez de 47. 

Estas son las normas basicas de los punteros: se puede guardar una direccion, y se 
puede utilizar dicha direccion para modificar la variable original. Pero la pregunta 
aun permanece: ^por que se querrla cambiar una variable utilizando otra variable 
como intermediario? 

Para esta vision introductoria a los punteros, podemos dividir la respuesta en dos 
grandes categorlas: 

1. Para cambiar «objetos externos» desde dentro de una funcion. Esto es quizas 
el uso mas basico de los punteros, y se examinara mas adelante. 

2. Para conseguir otras muchas tecnicas de programacion ingeniosas, sobre las 
que aprendera en el resto del libro. 

3.4.5. Modificar objetos externos 

Normalmente, cuando se pasa un argumento a una funcion, se hace una copia de 
dicho argumento dentro de la funcion. Esto se llama paso-por-valor. Se puede ver el 
efecto de un paso-por-valor en el siguiente programa: 

//: C03:PassByValue.cpp 

#include <iostream> 

using namespace std; 

void f (int a) { 

cout << "a = " << a << endl; 
a = 5; 

cout << "a = " << a << endl; 

} 

int main() { 

int x = 47; 

cout << "x = " << x << endl; 
f (x) ; 

cout << "x = " << x << endl; 

} ///:~ 


En f ( ), a es una variable local, de modo que existe unicamente mientras dura la 
llamada a la funcion f (). Como es un argumento de una funcion, el valor de a se 
inicializa mediante los argumentos que se pasan en la invocation de la funcion; en 
main () el argumento es x, que tiene un valor 47, de modo que el valor es copiado 
en a cuando se llama a f (). 

Cuando ejecute el programa vera: 

x = 47 
a = 47 
a = 5 
x = 47 
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Por supuesto, inicialmente x es 47. Cuando se llama f (), se crea un espacio tem¬ 
poral para alojar la variable a durante la ejecucion de la funcion, y el valor de x se 
copia a a, el cual es verificado mostrandolo por pantalla. Se puede cambiar el valor 
de a y demostrar que ha cambiado. Pero cuando f () termina, el espacio temporal 
que se habia creado para a desaparece, y se puede observar que la unica conexion 
que existia entre a y x ocurrio cuando el valor de x se copio en a. 

Cuando esta dentro de f (), x es el objeto externo (mi terminologia), y cambiar 
el valor de la variable local no afecta al objeto externo, lo cual es bastante logico, 
puesto que son dos ubicaciones separadas en la memoria. Pero iy si quiere modificar 
el objeto externo? Aqui es donde los punteros entran en accion. En cierto sentido, un 
puntero es un alias de otra variable. De modo que si a una funcion se le pasa un 
puntero en lugar de un valor ordinario, se esta pasando de hecho un alias del objeto 
externo, dando la posibilidad a la funcion de que pueda modificar el objeto externo, 
tal como sigue: 


//: C03:PassAddress.cpp 

#include <iostream> 

using namespace std; 


void f (int 

* p) 

{ 



cout 

<< 

"p = 

" << 

p « 

endl ; 

cout 

<< 

"*p = 

" « 

*p 

<< endl; 

*p = 

5; 





cout 

} 

<< 

"p = 

" « 

p « 

endl ; 

int main() 

{ 




int x 

: = 

47; 




cout 

<< 

"x = 

" « 

X << 

endl ; 

cout 

<< 

" & X = 

" << 

&X 

<< endl; 

f ( &x) 

r 





cout 

« 

"x = 

" << 

X << 

endl; 


} ///:- 


Ahora f () toma el puntero como un argumento y dereferencia el puntero duran¬ 
te la asignacion, lo que modifica el objeto externo x. La salida es: 


x = 47 

£x = 0065FE00 
p = 0065FE00 
*p = 47 
p = 0065FE00 
x = 5 


Tenga en cuenta que el valor contenido en p es el mismo que la direccion de x - 
el puntero p de hecho apunta a x. Si esto no es suficientemente convincente, cuando 
p es dereferenciado para asignarle el valor 5, se ve que el valor de x cambia a 5 
tambien. 

De ese modo, pasando un puntero a una funcion le permitira a esa funcion mo¬ 
dificar el objeto externo. Se veran muchos otros usos de los punteros mas adelante, 
pero podria decirse que este es el mas basico y posiblemente el mas comun. 
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3.4.6. Introduccion a las referencias de C++ 

Los punteros funcionan mas o menos igual en C y en C++, pero C++ anade un 
modo adicional de pasar una direccion a una funcion. Se trata del paso-por-referencia 
y existe en otros muchos lenguajes, de modo que no es una invencion de C++. 

La primera impresion que dan las referencias es que no son necesarias, que se 
pueden escribir cualquier programa sin referencias. En general, eso es verdad, con la 
excepcion de unos pocos casos importantes que se trataran mas adelante en el libro, 
pero la idea basica es la misma que la demostracion anterior con el puntero: se pue- 
de pasar la direccion de un argumento utilizando una referenda. La diferencia entre 
referencias y punteros es que invocar a una funcion que recibe referencias es mas 
limpio, sintacticamente, que llamar a una funcion que recibe punteros (y es exac- 
tamente esa diferencia sintactica la que hace a las referencias esenciales en ciertas 
situaciones). Si PassAddress. cpp se modifica para utilizar referencias, se puede 
ver la diferencia en la llama da a la funcion en main (): 

//: C03:PassReference.cpp 

#include <iostream> 

using namespace std; 

void f (int& r) { 

cout << "r = " << r << endl; 
cout << "&r = " << &r << endl; 
r = 5; 

cout << "r = " << r << endl; 

} 

int main() { 

int x = 4 7; 

cout << "x = " << x << endl; 
cout << "&x = " << &x << endl; 
f(x); // Looks like pass-by-value, 

// is actually pass by reference 
cout << "x = " << x << endl; 

} ///:- 


En la lista de argumentos de f (), en lugar de escribir int* para pasar un puntero, 
se escribe int& para pasar una referencia. Dentro de f () , si dice simplemente r (lo 
que produciria la direccion si r fuese un puntero) se obtiene el valor en la variable que 
r estd referenciando. Si se asigna a r, en realidad se esta asignado a la variable a la que 
que r referencia. De hecho, la unica manera de obtener la direccion que contiene r 
es con el operador &. 

En main (), se puede ver el efecto clave de las referencias en la sintaxis de la 
llamada a f () , que es simplemente f (x). Aunque eso parece un paso-por-valor 
ordinario, el efecto de la referencia es que en realidad toma la direccion y la pasa, en 
lugar de hacer una copia del valor. La salida es: 

x = 47 

&x = 0065FE00 
r = 47 

Sr = 0065FE00 
r = 5 
x = 5 

De manera que se puede ver que un paso-por-referencia permite a una funcion 
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modificar el objeto externo, al igual que al pasar un puntero (tambien se puede ob- 
servar que la referenda esconde el hecho de que se esta pasando una direccion; esto 
se vera mas adelante en el libro). Gracias a esta pequena introduccion se puede asu- 
mir que las referencias son solo un modo sintacticamente distinto (a veces referido 
como «azucar sintactico») para conseguir lo mismo que los punteros: permitir a las 
funciones cambiar los objetos externos. 


3.4.7. Punteros y Referencias como modificadores 

Hasta ahora, se han visto los tipos basicos de datos char, int, float, y double, junto 
con los especificadores signed, unsigned, short, y long, que se pueden utilizar con 
los tipos basicos de datos en casi cualquier combinacion. Ahora hemos anadido los 
punteros y las referencias, que son lo ortogonal a los tipos basicos de datos y los 
especificadores, de modo que las combinaciones posibles se acaban de triplicar: 

//: C03:AllDefinitions.cpp 

// All possible combinations of basic data types, 

// specifiers, pointers and references 
#include <iostream> 

using namespace std; 

void fl (char c, int i, float f , double d); 

void f2 (short int si, long int li, long double id); 

void f3 (unsigned char uc, unsigned int ui, 

unsigned short int usi, unsigned long int uli); 
void f4 (char* cp, int* ip, float* fp, double* dp) ; 
void f5 (short int* sip, long int* lip, 
long double* ldp) ; 

void f6 (unsigned char* ucp, unsigned int* nip, 
unsigned short int* usip, 
unsigned long int* ulip); 

void f7 (chars cr, ints ir, floats fr, doubles dr) ; 
void f8 (short ints sir, long ints lir, 
long doubles ldr) ; 

void f9 (unsigned chars ucr, unsigned ints uir, 
unsigned short ints usir, 
unsigned long ints ulir); 

int main() {} ///:- 


Los punteros y las referencias entran en juego tambien cuando se pasan objetos 
dentro y fuera de las funciones; aprendera sobre ello en un capitulo posterior. 

Hay otro tipo que funciona con punteros: void. Si se establece que un puntero es 
un void*, significa que cualquier tipo de direccion se puede asignar a ese puntero 
(en cambio si tiene un int*, solo puede asignar la direccion de una variable int a ese 
puntero). Por ejemplo: 

//: C03:VoidPointer.cpp 

int main() { 

void* vp; 
char c; 
int i; 
float f; 
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double d; 

// The address of ANY type can be 
// assigned to a void pointer: 
vp = & c; 
vp = & i; 
vp = & f; 
vp = & d; 

} ///:~ 


Una vez que se asigna a un void’ 1 ' se pierde cualquier informacion sobre el tipo 
de la variables. Esto significa que antes de que se pueda utilizar el puntero, se debe 
moldear al tipo correcto: 

//: C03:CastFromVoidPointer.cpp 

int main() { 
int i = 99; 
void* vp = &i; 

// Can't dereference a void pointer: 

// *vp = 3; // Compile-time error 

// Must cast back to int before dereferencing: 

*((int*) vp) =3; 

} ///:~ 


El molde ( int *) vp toma el void’ 1 ' y le dice al compilador que lo trate como un 
int”', y de ese modo se puede dereferenciar correctamente. Puede observar que esta 
sintaxis es horrible, y lo es, pero es peor que eso - el void’ 1 ' introduce un agujero en 
el sistema de tipos del lenguaje. Eso significa, que permite, o incluso promueve, el 
tratamiento de un tipo como si fuera otro tipo. En el ejemplo anterior, se trata un int 
como un int mediante el moldeado de vp a int’ 1 ', pero no hay nada que indique que no 
se lo puede moldear a char’ 1 ' o double’ 1 ', lo que modificaria una cantidad diferente de 
espacio que ha sido asignada al int, lo que posiblemente provocara que el programa 
falle.. En general, los punteros void deberian ser evitados, y utilizados unicamente 
en raras ocasiones, que no se podran considerar hasta bastante mas adelante en el 
libro. 

No se puede tener una referenda void, por razones que se explicaran en el capf- 
tulo 11. 


3.5. Alcance 

Las reglas de ambitos dicen cuando es valida una variable, donde se crea, y cuan- 
do se destruye (es decir, sale de ambito). El ambito de una variable se extiende desde 
el punto donde se define hasta la primera Have que empareja con la Have de apertura 
antes de que la variable fuese definida. Eso quiere decir que un ambito se define por 
su juego de llaves «mas cercanas». Para ilustrarlo: 

//: C03:Scope.cpp 
// How variables are scoped 
int main() f 
int scpl; 

// scpl visible here 
{ 
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// scpl still visible here 

// . 

int scp2; 

// scp2 visible here 

// . 

{ 

// scpl & scp2 still visible here 

/ / . . 

int scp3; 

// scpl, scp2 & scp3 visible here 

II... 

} // <-- scp3 destroyed here 
// scp3 not available here 
// scpl & scp2 still visible here 

II ... 

} // <— scp2 destroyed here 
// scp3 & scp2 not available here 
// scpl still visible here 

//. . 

} // <— scpl destroyed here 
III:- 


El ejemplo anterior muestra cuando las variables son visibles y cuando dejan de 
estar disponibles (es decir, cuando salen del dmbito). Una variable se puede utilizar 
solo cuando se esta dentro de su ambito. Los ambitos pueden estar anidados, indica- 
dos por parejas de llaves dentro de otras parejas de Haves. El anidado significa que 
se puede acceder a una variable en un ambito que incluye el ambito en el que se esta. 
En el ejemplo anterior, la variable scpl esta disponible dentro de todos los demas 
ambitos, mientras que scp3 solo esta disponible en el ambito mas interno. 


3.5.1. Definition de variables «al vuelo» 

Como se ha mencionado antes en este capitulo, hay una diferencia importan- 
te entre C y C++ al definir variables. Ambos lenguajes requieren que las variables 
esten definidas antes de utilizarse, pero C (y muchos otros lenguajes procedurales 
tradicionales) fuerzan a que se definan todas las variables al principio del bloque, 
de modo que cuando el compilador crea un bloque puede crear espacio para esas 
variables. 

Cuando uno lee codigo C, normalmente lo primero que encuentra cuando empie- 
za un ambito, es un bloque de definiciones de variables. Declarar todas las variables 
al comienzo de un bloque requiere que el programador escriba de un modo particu¬ 
lar debido a los detalles de implementacion del lenguaje. La mayoria de las personas 
no conocen todas las variables que van a utilizar antes de escribir el codigo, de modo 
que siempre estan volviendo al principio del bloque para insertar nuevas variables, 
lo cual resulta pesado y causa errores. Normalmente estas definiciones de variables 
no significan demasiado para el lector, y de hecho tienden a ser confusas porque 
aparecen separadas del contexto en el cual se utilizan. 

C++ (pero no C) permite definir variables en cualquier sitio dentro de un ambito, 
de modo que se puede definir una variable justo antes de usarla. Ademas, se puede 
inicializar la variable en el momento de la definicion, lo que previene cierto tipo 
de errores. Definir las variables de este modo hace el codigo mas facil de escribir 
y reduce los errores que provoca estar forzado a volver atras y adelante dentro de 
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un ambito. Hace el codigo mas facil de entender porque es una variable definida 
en el contexto de su utilizacion. Esto es especialmente importante cuando se esta 
definiendo e inicializando una variable al mismo tiempo - se puede ver el significado 
del valor de inicializacion por el modo en el que se usa la variable. 

Tambien se pueden definir variables dentro de expresiones de control tales como 
los bucles for y while, dentro de las sentencias de condiciones if, y dentro de 
la sentencia de seleccion switch. A continuacion hay un ejemplo que muestra la 
definicion de variables al-vuelo: 

//: C03:OnTheFly.cpp 
// On-the-fly variable definitions 

#include <iostream> 

using namespace std; 

int main() { 

{ // Begin a new scope 

int q = 0; // C requires definitions here 

// Define at point of use: 
for(int i = 0; i < 100; i++) { 

q++; // q comes from a larger scope 
// Definition at the end of the scope: 

int p = 12; 

} 

int p = 1; //A different p 

} // End scope containing q & outer p 

cout << "Type characters:" << endl; 
while(char c = cin. get() != 'q') { 

cout << c << " wasn't it" << endl; 
if(char x = c == 'a' II c == 'b') 
cout << "You typed a or b" << endl; 
else 

cout << "You typed " << x << endl; 

} 

cout << "Type A, B, or C" << endl; 
switch (int i = cin.getO) { 

case 'A': cout << "Snap" << endl; break; 
case 'B': cout << "Crackle" << endl; break; 
case ' C : cout << "Pop" << endl; break; 
default: cout << "Not A, B or C!" << endl; 

} 

} ///:~ 


En el ambito mas interno, se define p antes de que acabe el ambito, de modo que 
realmente es un gesto inutil (pero demuestra que se puede definir una variable en 
cualquier sitio). La variable p en el ambito exterior esta en la misma situacion. 

La definicion de i en la expresion de control del bucle f or es un ejemplo de que 
es posible definir una variable exactamente en el punto en el que se necesita (esto 
solo se puede hacer en C++). El ambito de i es el ambito de la expresion controlada 
por el bucle for, de modo que se puede re-utilizar i en el siguiente bucle for. Se 
trata de un modismo conveniente y comun en C++; i es el nombre habitual para el 
contador de un f or y asi no hay que inventar nombres nuevos. 

A pesar de que el ejemplo tambien muestra variables definidas dentro de las 
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sentencias while, if y switch, este tipo de definiciones es menos comun que las 
de expresiones for, quizas debido a que la sintaxis es mas restrictiva. Por ejemplo, 
no se puede tener ningun parentesis. Es decir, que no se puede indicar: 

while ((char c = cin.getO) != ' q' ) 

Anadir los parentesis extra pareceria una accion inocente y util, y debido a que no 
se pueden utilizar, los resultados no son los esperados. El problema ocurre porque ! = 
tiene orden de precedencia mayor que =, de modo que el char c acaba conteniendo 
un bool convertido a char. Cuando se muestra, en muchos terminales se veria el 
caracter de la cara sonriente. 

En general, se puede considerar la posibilidad de definir variables dentro de las 
sentencias while, if y switch por completitud, pero el unico lugar donde se de- 
beria utilizar este tipo de definition de variables es en el bucle for (donde usted las 
utilizara mas a menudo). 


3.6. Especificar la ubicacion del espacio de alma¬ 
cenamiento 

A1 crear una variable, hay varias alternativas para especificar la vida de dicha 
variable, la forma en que se decide la ubicacion para esa variable y como la tratara el 
compilador. 


3.6.1. Variables globales 

Las variables globales se definen fuera de todos los cuerpos de las funciones y 
estan disponibles para todo el programa (incluso el codigo de otros ficheros). Las 
variables globales no estan afectadas por ambitos y estan siempre disponibles (es 
decir, la vida de una variable global dura hasta la finalization del programa). Si la 
existencia de una variable global en un fichero se declara usando la palabra reserva- 
da extern en otro fichero, la information esta disponible para su utilization en el 
segundo fichero. A continuation, un ejemplo del uso de variables globales: 

//: C03:Global.cpp 
//{L} Global2 

// Demonstration of global variables 

#include <iostream> 

using namespace std; 

int globe; 
void func(); 
int main() { 

globe = 12; 

cout << globe << endl; 
func (); // Modifies globe 
cout << globe << endl; 

} /// : ~ 


Y el fichero que accede a globe como un extern: 
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//: C03:Global2.cpp {0} 

// Accessing external global variables 

extern int globe; 

// (The linker resolves the reference) 
void func() { 
globe = 47; 

} // / : ~ 


El espacio para la variable globe se crea mediante la definition en Global. cpp, 
y esa misma variable es accedida por el codigo de Globa 12 . cpp. Ya que el codigo 
de Global2 . cpp se compila separado del codigo de Global. cpp, se debeinformar 
al compilador de que la variable existe en otro sitio mediante la declaration 

extern int globe; 


Cuando ejecute el programa, observara que la llamada fun () afecta efectiva- 
mente a la linica instancia global de globe. 

En Global. cpp, se puede ver el comentario con una marca especial (que es di- 
seno mio): 

//{L} Global2 

Eso indica que para crear el programa final, el fichero objeto con el nombre G1 oba 12 
debe estar enlazado (no hay extension ya que los nombres de las extensiones de 
los ficheros objeto difieren de un sistema a otro). En Global2 . cpp, la primera li- 
nea tiene otra marca especial {O}, que significa «No intentar crear un ejecutable 
de este fichero, se compila para que pueda enlazarse con otro fichero». El progra¬ 
ma ExtractCode . cpp en el Volumen 2 de este libro (que se puede descargar de 
www.BruceEckel.com) lee estas marcas y crea el makefile apropiado de modo que 
todo se compila correctamente (aprendera sobre makefiles al final de este capitulo). 


3.6.2. Variables locales 

Las variables locales son las que se encuentran dentro de un ambito; son «loca- 
les» a una funcion. A menudo se las llama variables automaticas porque aparecen 
automaticamente cuando se entra en un ambito y desaparecen cuando el ambito se 
acaba. La palabra reservada auto lo enfatiza, pero las variables locales son auto por 
defecto, de modo que nunca se necesita realmente declarar algo como auto. 

Variables registro 

Una variable registro es un tipo de variable local. La palabra reservada regis¬ 
ter indica al compilador «Haz que los accesos a esta variable sean lo mas rapidos 
posible». Aumentar la velocidad de acceso depende de la implementation, pero, tal 
como sugiere el nombre, a menudo se hace situando la variable en un registro del 
microprocesador. No hay garantia alguna de que la variable pueda ser ubicada en 
un registro y tampoco de que la velocidad de acceso aumente. Es una ayuda para el 
compilador. 

Hay restricciones a la hora de utilizar variables registro. No se puede consular 
o calcular la direction de una variable registro. Una variable registro solo se puede 
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declarar dentro de un bloque (no se pueden tener variables de registro globales o 
estaticas). De todos modos, se pueden utilizar como un argumento formal en una 
funcion (es decir, en la lista de argumentos). 

En general, no se deberia intentar influir sobre el optimizador del compilador, ya 
que probablemente el hara mejor el trabajo de lo que lo pueda hacer usted. Por eso, 
es mejor evitar el uso de la palabra reservada register. 


3.6.3. Static 

La palabra reservada static tiene varios significados. Normalmente, las va¬ 
riables definidas localmente a una funcion desaparecen al final del ambito de esta. 
Cuando se llama de nuevo a la funcion, el espacio de las variables se vuelve a pedir 
y las variables son re-inicializadas. Si se desea que el valor se conserve durante la 
vida de un programa, puede definir una variable local de una funcion como static 
y darle un valor inicial. La inicializacion se realiza solo la primera vez que se llama a 
la funcion, y la informacion se conserva entre invocaciones sucesivas de la funcion. 
De este modo, una funcion puede «recordar» cierta informacion entre una llamada 
y otra. 

Puede surgir la duda de porque no utilizar una variable global en este caso. El 
encanto de una variable static es que no esta disponible fuera del ambito de la 
funcion, de modo que no se puede modificar accidentalmente. Esto facilita la locali¬ 
zation de errores. 

A continuation, un ejemplo del uso de variables static: 

//: C03:Static.cpp 

// Using a static variable in a function 

#include <iostream> 

using namespace std; 

void func() { 

static int i = 0; 

cout << "i = " << ++i << endl; 

} 

int main() { 

for(int x = 0; x < 10; x++) 
func (); 

} ///:- 


Cada vez que se llama a func () dentro del bucle, se imprime un valor diferente. 
Si no se utilizara la palabra reservada static, el valor mostrado seria siempre 1. 

El segundo significado de static esta relacionado con el primero en el sentido 
de que «no esta disponible fuera de cierto ambito». Cuando se aplica static al 
nombre de una funcion o de una variable que esta fuera de todas las funciones, 
significa «Este nombre no esta disponible fuera de este fichero». El nombre de la 
funcion o de la variable es local al fichero; decimos que tiene ambito de fichero. Como 
demostracion, al compilar y enlazar los dos ficheros siguientes aparece un error en 
el enlazado: 

//: C03:FileStatic.cpp 

// File scope demonstration. Compiling and 
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// linking this file with FileStatic2.cpp 
// will cause a linker error 

// File scope means only available in this file: 

static int fs; 

int main () { 

f s = 1 ; 

} ///:- 


Aunque la variable f s esta destinada a existir como un extern en el siguiente fi- 
chero, el enlazador no la encontraria porqueha sido declarada static en File St at ic . 

cpp. 

//: C03:FileStatic2.cpp {0} 

// Trying to reference fs 

extern int fs; 
void func() { 
fs = 100; 

i ///:- 


El especificador static tambien se puede usar dentro de una clase. Esta expli¬ 
cation se dara mas adelante en este libro, cuando aprenda a crear clases. 


3.6.4. extern 

La palabra reservada extern ya ha sido brevemente descripta. Le dice al com- 
pilador que una variable o una funcion existe, incluso si el compilado aun no la ha 
visto en el fichero que esta siendo compilado en ese momento. Esta variable o fun¬ 
cion puede definirse en otro fichero o mas abajo en el fichero actual. A modo de 
ejemplo: 

//: C03:Forward.cpp 

// Forward function & data declarations 

#include <iostream> 

using namespace std; 

// This is not actually external, but the 
// compiler must be told it exists somewhere: 

extern int i; 
extern void func(); 
int main() { 

i = 0; 
func (); 

} 

int i; // The data definition 

void func() { 
i + + ; 

cout << i; 

} ///:- 
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Cuando el compilador encuentra la declaracion extern int i sabe que la de- 
finicion para i debe existir en algun sitio como una variable global. Cuando el com¬ 
pilador alcanza la definicion de i, ninguna otra declaracion es visible, de modo que 
sabe que ha encontrado la misma i declarada anteriormente en el fichero. Si se hu- 
biera definido i como static, estaria indicando al compilador que i se define glo- 
balmente (por extern), pero tambien que tiene el ambito de fichero (por static), 
de modo que el compilador generara un error. 

Enlazado 

Para comprender el comportamiento de los programas C y C++, es necesario 
saber sobre enlazado. En un programa en ejecucion, un identificador se representa 
con espacio en memoria que aloja una variable o un cuerpo de funcion compilada. 
El enlazado describe este espacio tal como lo ve el enlazador. Hay dos formas de 
enlazado: enlace interno y enlace externo. 

Enlace interno significa que el espacio se pide para representar el identificador so¬ 
lo durante la compilacion del fichero. Otros ficheros pueden utilizar el mismo nom- 
bre de identificador con un enlace interno, o para una variable global, y el enlazador 
no encontraria conflictos - se pide un espacio separado para cada identificador. El 
enlace interno se especifica mediante la palabra reservada static en C y C++. 

Enlace externo significa que se pide solo un espacio para representar el identifi¬ 
cador para todos los ficheros que se esten compilando. El espacio se pide una vez, y 
el enlazador debe resolver todas las demas referencias a esa ubicacion. Las variables 
globales y los nombres de funcion tienen enlace externo. Son accesibles desde otros 
ficheros declarandolas con la palabra reservada extern. Por defecto, las variables 
definidas fuera de todas las funciones (con la excepcion de const en C++) y las defi- 
niciones de las funciones implican enlace externo. Se pueden forzar espedficamente 
a tener enlace interno utilizando static. Se puede establecer explicitamente que un 
identificador tiene enlace externo definiendolo como extern. No es necesario defi- 
nir una variable o una funcion como extern en C, pero a veces es necesario para 
const en C++. 

Las variables automaticas (locales) existen solo temporalmente, en la pila, mien- 
tras se esta ejecutando una funcion. El enlazador no entiende de variables automati¬ 
cas, de modo que no tienen enlazado. 


3.6.5. Constantes 

En el antiguo C (pre-Estandar), si se deseaba crear una constante, se debia utilizar 
el preprocesador: 

#define PI 3.14159 


En cualquier sitio en el que utilizase PI, el preprocesador lo substituia por el valor 
3.14159 (aun se puede utilizar este metodo en C y C++). 

Cuando se utiliza el preprocesador para crear constantes, su control queda fuera 
del ambito del compilador. No existe ninguna comprobacion de tipo y no se puede 
obtener la direccion de PI (de modo que no se puede pasar un puntero o una re¬ 
ferenda a PI). PI no puede ser una variable de un tipo definido por el usuario. El 
significado de PI dura desde el punto en que es definida, hasta el final del fichero; el 
preprocesador no entiende de ambitos. 
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C++ introduce el concepto de constantes con nombre que es lo mismo que va¬ 
riable, excepto que su valor no puede cambiar. El modificador const le indica al 
compilador que el nombre representa una constante. Cualquier tipo de datos prede- 
finido o definido por el usuario, puede ser definido como const. Si se define algo 
como const y luego se intenta modificar, el compilador generara un error. 

Se debe especificar el tipo de un const, de este modo: 

const int x = 10; 



En C y C++ Estandar, se puede usar una constante en una lista de argumentos, 
incluso si el argumento que ocupa es un puntero o una referenda (p.e, se puede 
obtener la direccion de una constante). Las constantes tienen ambito, al igual que 
una variable ordinaria, de modo que se puede «esconder» una constante dentro de 
una funcion y estar seguro de que ese nombre no afectara al resto del programa. 

const ha sido tornado de C++ e incorporado al C Estandar pero un modo un 
poco distinto. En C, el compilador trata a const del mismo modo que a una variable 
que tuviera asociado una etiqueta que dice «No me cambies». Cuando se define un 
const en C, el compilador pide espacio para el, de modo que si se define mas de un 
const con el mismo nombre en dos ficheros distintos (o se ubica la definicion en un 
fichero de cabeceras), el enlazador generara mensajes de error sobre del conflicto. El 
concepto de const en C es diferente de su utilizacion en C++ (en resumen, es mas 
bonito en C++). 

Valores constantes 

En C++, una constante debe tener siempre un valor inicial (En C, eso no es cierto). 
Los valores de las constantes para tipos predefinidos se expresan en decimal, octal, 
hexadecimal, o numeros con punto flotante (desgraciadamente, no se considero que 
los binarios fuesen importantes), o como caracteres. 

A falta de cualquier otra pista, el compilador assume que el valor de una cons¬ 
tante es un numero decimal. Los numeros 47, 0 y 1101 se tratan como numeros deci- 
males. 

Un valor constante con un cero al principio se trata como un numero octal (base 
8). Los numeros con base 8 pueden contener unicamente digitos del 0 al 7; el compi¬ 
lador interpreta otros digitos como un error. Un numero octal legitimo es 017 (15 en 
base 10). 

Un valor constante con Ox al principio se trata como un numero hexadecimal 
(base 16). Los numeros con base 16 pueden contener digitos del 0 al 9 y letras de la a 
a la f o A a F. Un numero hexadecimal legitimo es Oxlfe (510 en base 10). 

Los numeros en punto flotante pueden contener comas decimales y potencias 
exponenciales (representadas mediante e, lo que significa «10 elevado a»). Tanto el 
punto decimal como la e son opcionales. Si se asigna una constante a una variable 
de punto flotante, el compilador tomara el valor de la constante y la convertira a 
un numero en punto flotante (este proceso es una forma de lo que se conoce como 
conversion implicita de tipo). De todos modos, es una buena idea el usar el punto 
decimal o una e para recordar al lector que esta utilizando un numero en punto 
flotante; algunos compiladores incluso necesitan esta pista. 

Algunos valores validos para una constante en punto flotante son: le4, 1.0001, 
47.0, 0.0 y 1.159e-77. Se pueden anadir sufijos para forzar el tipo de numero de pun¬ 
to flotante: f o F fuerza que sea float, L o 1 fuerza que sea un long double; de lo 
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contrario, el numero sera un double. 

Las constantes de tipo char son caracteres entre comillas simples, tales como: ' - 
A', ' o', ' '. Frjese en que hay una gran diferencia entre el caracter ' o' (ASCII 96) 
y el valor 0. Los caracteres especiales se representan con la «barra invertida»: ' \n' 
(nueva linea), ' \t' (tabulacion), ' \ \' (barra invertida), ' \r' (retorno de carro), ' - 
\ " ' (comilla doble),' \' ' (comilla simple), etc. Incluso se puede expresar constantes 
de tipo char en octal: ' \17' o hexadecimal: ' \xf f'. 


3.6.6. Volatile 

Mientras que el calificador const indica al compilador «Esto nunca cambia» (lo 
que permite al compilador realizar optimizaciones extra), el calificador volatile 
dice al compilador «Nunca se sabe cuando cambiara esto», y evita que el compila¬ 
dor realice optimizaciones basadas en la estabilidad de esa variable. Se utiliza esta 
palabra reservada cuando se lee algun valor fuera del control del codigo, algo asi 
como un registro en un hardware de comunicacion. Una variable volatile se lee 
siempre que su valor es requerido, incluso si se ha leido en la linea anterior. 

Un caso especial de espacio que esta «fuera del control del codigo» es en un pro- 
grama multi-hilo. Si esta comprobando una bandera particular que puede ser modi- 
ficada por otro hilo o proceso, esta bandera deberia ser volatile de modo que el 
compilador no asuma que puede optimizar multiples lecturas de la bandera. 

Frjese en que volatile puede no tener efecto cuando el compilador no esta 
optimizando, pero puede prevenir errores criticos cuando se comienza a optimizar 
el codigo (que es cuando el compilador empezara a buscar lecturas redundantes). 

Las palabras reservadas const y volatile se veran con mas detalle en un ca- 
pitulo posterior. 


3.7. Los operadores y su uso 

Esta seccion cubre todos los operadores de C y C++. 

Todos los operadores producen un valor a partir de sus operandos. Esta opera- 
cion se efectua sin modificar los operandos, excepto con los operadores de asigna¬ 
cion, incremento y decremento. El hecho de modificar un operando se denomina 
efecto colateral. El uso mas comun de los operadores que modifican sus operandos es 
producir el efecto colateral, pero se deberia tener en cuenta que el valor producido 
esta disponible para su uso al igual que el de los operadores sin efectos colaterales. 


3.7.1. Asignacion 

La asignacion se realiza mediante el operador =. Eso significa «Toma el valor 
de la derecha (a menudo llamado rvalue) y copialo en la variable de la izquierda 
(a menudo llamado lvalue).» Un rvalue es cualquier constante, variable o expresion 
que pueda producir un valor, pero un lvalue debe ser una variable con un nombre 
distintivo y unico (esto quiere decir que debe haber un espacio fisico donde guardar 
la informacion). De hecho, se puede asignar el valor de una constante a una variable 
(A = 4 ;), pero no se puede asignar nada a una constante - es decir, una constante 
no puede ser un lvalue (no se puede escribir 4 = A;). 



Volumenl" — 2012/1/12 — 13:52 — page 96 — #134 


Capitulo 3. C en C++ 


3.7.2. Operadores matematicos 

Los operadores matematicos basicos son los mismos que estan disponibles en 
la mayoria de los lenguajes de programacion: adicion (+), substraccion (-), division 
(/), multiplication (*), y modulo (%; que produce el resto de una division entera). 
La division entera trunca el resultado (no lo redondea). El opera dor modulo no se 
puede utilizar con numeros con punto flotante. 

C y C++ tambien utilizan notaciones abreviadas para efectuar una operacion y 
una asignacion al mismo tiempo. Esto se denota por un operador seguido de un 
signo igual, y se puede aplicar a todos los operadores del lenguaje (siempre que 
tenga sentido). Por ejemplo, para ana dir 4 a la variable x y asignar x al resultado, se 
escribe: x += 4 ;. 

Este ejemplo muestra el uso de los operadores matematicos: 

//: C03:Mathops.cpp 
// Mathematical operators 

#include <iostream> 

using namespace std; 

//A macro to display a string and a value. 

#define PRINT(STR, VAR) \ 

cout « STR " = " << VAR << endl 

int main () { 

int i , j , k ; 

float u, v, w; // Applies to doubles, too 
cout << "enter an integer: 
cin >> j; 

cout << "enter another integer: 
cin >> k; 

PRINT("j",j); PRINT("k",k); 
i = j + k; PRINT("j + k",i); 

i = j - k; PRINT("j - k",i); 

i = k / j; PRINT("k / j",i); 

i = k * j; PRINT("k * j",i); 

i = k % j; PRINT("k % j",i); 

// The following only works with integers: 
j %= k; PRINT("j %= k", j); 
cout << "Enter a floating-point number: 
cin >> v; 

cout << "Enter another floating-point number:"; 
cin >> w; 

PRINT("v",v); PRINT("w",w); 


U = V 

+ 

w; 

PRINT ( "v 

+ 

w" f 

U) 

U = V 

- 

w; 

PRINT("v 

- 

w ", 

U) 

U = V 

•k 

w; 

PRINT ( "v 

•k 

w", 

U) 

U = V 

/ 

w; 

PRINT ( "v 

/ 

w ", 

U) 


// The following works for ints, chars, 
// and doubles too: 

PRINT ("u", U); PRINT("v", v); 
u += v; PRINT ("u += v", u); 

u -= v; PRINT ("u -= v", u); 

u *= v; PRINT ("u *= v", u); 

u /= v; PRINT ("u /= v", u); 

} ///:- 
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Los rvalues de todas las asignaciones pueden ser, por supuesto, mucho mas com- 
plejos. 

Introduction a las macros del preprocesador 

Observe el uso de la macro PRINT () para ahorrar lineas (y errores de sintaxis!). 
Las macros de preprocesador se nombran tradicionalmente con todas sus letras en 
mayusculas para que sea facil distinguirlas - aprendera mas adelante que las macros 
pueden ser peligrosas (y tambien pueden ser muy utiles). 

Los argumentos de de la lista entre parentesis que sigue al nombre de la macro 
son sustituidos en todo el codigo que sigue al parentesis de cierre. El preprocesador 
elimina el nombre PRINT y sustituye el codigo donde se invoca la macro, de modo 
que el compilador no puede generar ningun mensaje de error al utilizar el nombre 
de la macro, y no realiza ninguna comprobacion de sintaxis sobre los argumentos 
(esto lo ultimo puede ser beneficioso, como se muestra en las macros de depuracion 
al final del capitulo). 


3.7.3. Operadores relacionales 

Los operadores relacionales establecen una relacion entre el valor de los operan- 
dos. Producen un valor booleano (especificado con la palabra reservada bool en C++) 
true si la relacion es verdadera, y false si la relacion es falsa. Los operadores re¬ 
lacionales son: menor que (<), mayor que (>), menor o igual a (<=), mayor o igual a 
(>=), equivalente (==), y distinto (! =). Se pueden utilizar con todos los tipos de datos 
predefinidos en C y C++. Se pueden dar definiciones especiales para tipos definidos 
por el usuario en C++ (aprendera mas sobre el tema en el Capitulo 12, que cubre la 
sobrecarga de operadores). 


3.7.4. Operadores logicos 

Los operadores logicos and (&&) y or (| |) producen true o false basandose en 
la relacion logica de sus argumentos. Recuerde que en C y C++, una condicion es 
cierta si tiene un valor diferente de cero, y falsa si vale cero. Si se imprime un bool, 
por lo general vera un 1' para true y 0 para false. 

Este ejemplo utiliza los operadores relacionales y logicos: 

//: C03:Boolean.cpp 

// Relational and logical operators. 

#include <iostream> 

using namespace std; 


int main () 

{ 





int 

i/ j; 






cout 

<< 

"Enter 

an integer: 



cin 

>> i 

t 





cout 

<< 

"Enter 

another integer: 

II . 

r 


cin 

-m 

A 

A 

r 





cout 

<< 

"i 

> j 

is " << (i > j) 

« endl; 

cout 

<< 

"i 

< j 

is " << (i < j) 

<< endl; 

cout 

<< 

"i 

-m 

II 

A 

is " << (i >= j 

) « 

endl 

cout 

<< 

"i 

-m 

II 

V 

is " << (i <= j 

) « 

endl 

cout 

<< 

"i 

== j 

is " << (i == j 

) « 

endl 

cout 

<< 

"i 

! = j 

is " << (i != j 

) « 

endl 
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cout 

<< 

"± & & j is " << 

(i && 

j) << endl; 

cout 

<< 

"i II j is " << 

(i 1 1 

j) << endl; 

cout 

<< 

" (i < 10) && (; 

j < 10) 

is " 

///:• 

<< 

((i < 10) && (j 

< 10) ) 

<< endl; 


Se puede reemplazar la definicion de int con float o double en el programa an¬ 
terior. De todos modos, dese cuenta de que la comparacion de un numero en punto 
flotante con el valor cero es estricta; un numero que es la fraccion mas pequena dife- 
rente de otro numero aun se considera «distinto de». Un numero en punto flotante 
que es poca mayor que cero se considera verdadero. 


3.7.5. Operadores para bits 

Los operadores de bits permiten manipular bits individuales y dar como salida 
un numero (ya que los valores con punto flotante utilizan un formato interno espe¬ 
cial, los operadores de bitS solo funcionan con tipos enteros: char, int y long). Los 
operadores de bitS efectuan algebra booleana en los bits correspondientes de los ar- 
gumentos para producir el resultado. 

El opera dor and (&) para bits produce uno en la salida si ambos bits de entrada 
valen uno; de otro modo produce un cero. El operador or (|) para bits produce un 
uno en la salida si cualquiera de los dos valores de entrada vale uno, y produce un 
cero solo si ambos valores de entrada son cero. El operador or exclusivo o xor (' ) para 
bits produce uno en la salida si uno de los valores de entrada es uno, pero no ambos. 
El operador not (~) para bits (tambien llamado operador de complemento a uno) es 
un operador unario - toma un unico argumento (todos los demas operadores son 
binarios). El operador not para bits produce el valor contrario a la entrada - uno si el 
bit de entrada es cero, y cero si el bit de entrada es uno. 

Los operadores de bits pueden combinarse con el signo = para unir la operacion y 
la asignacion: & =, | =, y ~ = son todas operaciones legales (dado que ~ es un operador 
unario no puede combinarse con el signo =). 


3.7.6. Operadores de desplazamiento 

Los operadores de desplazamiento tambien manipulan bits. El operador de des¬ 
plazamiento a izquierda (<<) produce el desplazamiento del operando que aparece 
a la izquierda del operador tantos bits a la izquierda como indique el numero a la 
derecha del operador. El operador de desplazamiento a derecha (>>) produce el des¬ 
plazamiento del operando de la izquierda hacia la derecha tantos bits como indique 
el numero a la derecha del operador. Si el valor que sigue al operador de desplaza¬ 
miento es mayor que el numero de bits del lado izquierdo, el resultado es indefinido. 
Si el operando de la izquierda no tiene signo, el desplazamiento a derecha es un des¬ 
plazamiento logico de modo que los bits del principio se rellenan con ceros. Si el 
operando de la izquierda tiene signo, el desplazamiento derecho puede ser un des¬ 
plazamiento logico (es decir, significa que el comportamiento es indeterminado). 

Los desplazamientos pueden combinarse con el signo igual (<<= y >>=)• El lvalue 
se reemplaza por lvalue desplazado por el rvalue. 

Lo que sigue a continuacion es un ejemplo que demuestra el uso de todos los 
operadores que involucran bits. Primero, una funcion de proposito general que im- 
prime un byte en formato binario, creada para que se pueda reutilizar facilmente. El 
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fichero de cabecera declara la funcion: 

//: C03:printBinary.h 
// Display a byte in binary 

void printBinary (const unsigned char val); 

///■: — 


A continuation la implementation de la funcion: 

//: C03:printBinary.cpp {0} 

#include <iostream> 

void printBinary (const unsigned char val) { 
for(int i = 7; i >= 0; i—) 
if (val & (1 << i) ) 

std::cout << "1" ; 

else 

std::cout << "0"; 

} ///:~ 


La funcion printBinary () toma un unico byte y lo muestra bit a bit. La expre- 
sion: 

(1 « i) 


produce un uno en cada posicion sucesiva de bit; enbinario: 00000001, 00000- 
010, etc. Si se hace and a este bit con val y el resultado es diferente de cero, significa 
que habia un uno en esa posicion de val. 

Finalmente, se utiliza la funcion en el ejemplo que muestra los operadores de 
manipulation de bits: 

//: C03:Bitwise.cpp 
//{L} printBinary 

// Demonstration of bit manipulation 

#include "printBinary.h" 

#include <iostream> 

using namespace std; 

// A macro to save typing: 

#define PR(STR, EXPR) \ 

cout << STR; printBinary(EXPR); cout << endl; 

int main () { 

unsigned int getval; 
unsigned char a, b; 

cout << "Enter a number between 0 and 255: 
cin >> getval; a = getval; 

PR("a in binary: ", a); 

cout << "Enter a number between 0 and 255: "; 
cin >> getval; b = getval; 

PR("b in binary: ", b); 

PR("a I b = ", a | b); 

PR ("a & b = ", a & b) ; 
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PR ("a A b = ", a A b) ; 

PR("~a = ", ~a) ; 

PR("~b = ", ~b); 

// An interesting bit pattern: 

unsigned char c = 0x5A; 

PR("c in binary: ", c) ; 
a b- c; 

PR ("a = c; a = ", a) ; 
b &= c; 

PR("b &= c; b = ", b); 
b A = a; 

PR("b A = a; b = ", b); 

} ///:~ 


Una vez mas, se usa una macro de preprocesador para ahorrar lineas. Imprime 
la cadena elegida, luego la representation binaria de una expresion, y luego un salto 
de linea. 

En main (), las variables son unsigned. Esto es porque, en general, no se desean 
signos cuando se trabaja con bytes. Se debe utilizar un int en lugar de un char para 
getval porque de otro modo la sentencia cin >> trataria el primer digito como un 
caracter. Asignando getval a a y b, se convierte el valor a un solo byte (truncando- 
lo). 

Los operadores << y >> proporcionan un comportamiento de desplazamiento de 
bits, pero cuando desplazan bits que estan al final del numero, estos bits se pierden 
(comunmente se dice que se caen en el mitico cubo de bits, el lugar donde acaban 
los bits descartados, presumiblemente para que puedan ser utilizados...). Cuando se 
manipulan bits tambien se pueden realizar rotaciones ; es decir, que los bits que salen 
de uno de los extremos se pueden insertar por el otro extremo, como si estuviesen 
rotando en un bucle. Aunque la mayoria de los procesadores de ordenadores ofrecen 
un comando de rotacion a nivel maquina (se puede ver en el lenguaje ensamblador 
de ese procesador), no hay un soporte directo para rotate en C o C++. Se supone que 
a los disenadores de C les parecio justificado el hecho de prescindir de rotate (en pro, 
como dijeron, de un lenguaje minimalista) ya que el programador se puede construir 
su propio comando rotate. Por ejemplo, a continuation hay funciones para realizar 
rotaciones a izquierda y derecha: 

//: C03:Rotation.cpp {0} 

// Perform left and right rotations 

unsigned char rol (unsigned char val) { 

int highbit; 

if (val & 0x80) // 0x80 is the high bit only 

highbit = 1; 

else 

highbit = 0; 

// Left shift (bottom bit becomes 0): 

val <<= 1; 

// Rotate the high bit onto the bottom: 

val |= highbit; 

return val; 

} 


unsigned char ror(unsigned char val) { 
int lowbit; 
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if (val & 1) // Check the low bit 

lowbit = 1; 

else 

lowbit = 0; 

val >>= 1; // Right shift by one position 
// Rotate the low bit onto the top: 
val |= (lowbit << 7); 
return val; 

} ///:~ 


A1 intentar utilizar estas funciones en Bitwise . cpp, advierta que las definicio- 
nes (o cuando menos las declaraciones) de rol () y ror () deben ser vistas por el 
compilador en Bitwise . cpp antes de que se puedan utilizar. 

Las funciones de tratamiento de bits son por lo general extremadamente eficien- 
tes ya que traducen directamente las sentencias a lenguaje ensamblador. A veces una 
sentencia de C o C++ generara una unica linea de codigo ensamblador. 


3.7.7. Operadores unarios 

El not no es el unico operador de bits que toma solo un argumento. Su companero, 
el not logico (!), toma un valor true y produce un valor false. El menos unario 
(-) y el mas unario (+) son los mismos operadores que los binarios menos y mas; el 
compilador deduce que uso se le pretende dar por el modo en el que se escribe la 
expresion. De hecho, la sentencia: 

x = -a; 


tiene un significado obvio. El compilador puede deducir: 

x = a * -b ; 


pero el lector se puede confundir, de modo que es mas seguro escribir: 

x = a * (-b) ; 


El menos unario produce el valor negativo. El mas unario ofrece simetria con el 
menos unario, aunque en realidad no hace nada. 

Los operadores de incremento y decremento (++ y —) se comentaron ya en este 
capitulo. Son los unicos operadores, ademas de los que involucran asignacion, que 
tienen efectos colaterales. Estos operadores incrementan o decrementan la variable 
en una unidad, aunque «unidad» puede tener diferentes significados dependiendo 
del tipo de dato - esto es especialmente importante en el caso de los punteros. 

Los ultimos operadores unarios son direccion-de (&), indireccion (* y ->), los 
operadores de moldeado en C y C++, y new y delete en C++. La direccion-de y la 
indireccion se utilizan con los punteros, descriptos en este capitulo. El moldeado se 
describe mas adelante en este capitulo, y new y delete se introducen en el Capitulo 
4. 




'Volumenl" — 2012/1/12 — 13:52 — page 102 — #140 


Capitulo 3. C en C++ 

3.7.8. El operador ternario 

El if-else ternario es inusual porque tiene tres operandos. Realmente es un 
operador porque produce un valor, al contrario de la sentencia ordinaria if-else. 
Consta de tres expresiones: si la primera expresion (seguida de un ?) se evalua como 
cierto, se devuelve el resultado de evaluar la expresion que sigue al ?. Si la primera 
expresion es falsa, se ejecuta la tercera expresion (que sigue a :) y su resultado se 
convierte en el valor producido por el operador. 

El operador condicional se puede usar por sus efectos colaterales o por el valor 
que produce. A continuation, un fragmento de codigo que demuestra ambas cosas: 

j a = —b ? b : (b = -99) ; 

Aqui, el condicional produce el rvalue. A a se le asigna el valor de b si el resultado 
de decrementar b es diferente de cero. Si b se queda a cero, a y b son ambas asignadas 
a -99. b siempre se decrementa, pero se asigna a -99 solo si el decremento provoca 
que b valga 0. Se puede utilizar un sentencia similar sin el a = solo por sus efectos 
colaterales: 

j —b ? b : (b = -99) ; 

Aqui la segunda b es superflua, ya que no se utiliza el valor producido por el 
operador. Se requiere una expresion entre el ? y :. En este caso, la expresion puede 
ser simplemente una constante, lo que haria que el codigo se ejecute un poco mas 
rapido. 



3.7.9. El operador coma 

La coma no se limita a separar nombres de variables en definiciones multiples, 
tales como 

int i, j, k; 

Por supuesto, tambien se usa en listas de argumentos de funciones. De todos mo- 
dos, tambien se puede utilizar como un operador para separar expresiones - en este 
caso produce el valor de la ultima expresion. El resto de expresiones en la lista sepa- 
rada por comas se evalua solo por sus efectos colaterales. Este ejemplo incrementa 
una lista de variables y usa la ultima como el rvalue-. 

//: C03:CommaOperator.cpp 

#include <iostream> 

using namespace std; 
int main 0 { 

int a = 0, b = l, c = 2, d=3, e = 4; 
a = (b+ + , C++, d++, e++) ; 

cout << "a = " << a << endl; 

// The parentheses are critical here. Without 
// them, the statement will evaluate to: 

(a = b++), C++, d++, e++; 

cout << "a = " << a << endl; 

} ///:- 
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En general, es mejor evitar el uso de la coma para cualquier otra cosa que no sea 
separar, ya que la gente no esta acostumbrada a verla como un operador. 


3.7.10. Trampas habituales cuando se usan operadores 

Como se ha ilustrado anteriormente, una de las trampas al usar operadores es 
tratar de trabajar sin parentesis incluso cuando no se esta seguro de la forma en la 
que se va a evaluar la expresion (consulte su propio manual de C para comprobar el 
orden de la evaluation de las expresiones). 

Otro error extremadamente comun se ve a continuation: 

//: C03:Pitfall.cpp 
// Operator mistakes 

int main () { 

int a = 1, b = 1; 
while (a = b) { 


} ///:- 


La sentencia a = b siempre se va a evaluar como cierta cuando b es distinta de 
cero. La variable a obtiene el valor de b, y el valor de b tambien es producido por 
el operador =. En general, lo que se pretende es utilizar el operador de equivalencia 
(== dentro de una sentencia conditional, no la asignacion. Esto le ocurre a muchos 
programadores (de todos modos, algunos compiladores advierten del problema, lo 
cual es una ayuda). 

Un problema similar es usar los operadores and y or de bits en lugar de sus equi- 
valentes logicos. Los operadores and y or de bits usan uno de los caracteres (& o |), 
mientras que los operadores logicos utilizan dos (&& y | I). Al igual que con = y ==, 
es facil escribir simplemente un caracter en vez de dos. Una forma muy facil de recor- 
darlo es que «los bits son mas pequenos, de modo que no necesitan tantos caracteres 
en sus operadores». 


3.7.11. Operadores de moldeado 

La palabra molde(azsf) se usa en el sentido de "colocar dentro de un molde'. El 
compilador cambiara automaticamente un tipo de dato a otro si tiene sentido. De 
hecho, si se asigna un valor entero a una variable de punto flotante, el compilador 
llamara secretamente a una funcion (o mas probablemente, insertara codigo) para 
convertir el int a un float. El molde permite hacer este tipo de conversion explicita, o 
forzarla cuando normalmente no pasaria. 

Para realizar un molde, se debe situar el tipo deseado (incluyendo todos los mo- 
dificadores) dentro de parentesis a la izquierda del valor. Este valor puede ser una 
variable, una constante, el valor producido por una expresion, o el valor devulto por 
una funcion. A continuation, un ejemplo: 

//: C03:SimpleCast.cpp 

int main() { 

int b = 200; 
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unsigned long a = (unsigned long int)b; 

} ///:~ 


El moldeado es poderoso, pero puede causar dolores de cabeza porque en algu- 
nas situaciones fuerza al compilador a tratar datos como si fuesen (por ejemplo) mas 
largos de lo que realmente son, de modo que ocupara mas espacio en memoria; lo 
que puede afectar a otros datos. Esto ocurre a menudo cuando se moldean punteros, 
no cuando se hacen moldes simples como los que ha visto anteriormente. 

C++ tiene una sintaxis adicional para moldes, que sigue a la sintaxis de llamada 
a funciones. Esta sintaxis pone los parentesis alrededor del argumento, como en una 
llamada a funcion, en lugar de a los lados del tipo: 

//: C03:FunctionCallCast.cpp 

int main() { 

float a = float (200); 

// This is equivalent to: 

float b = (float) 200; 

} ///:- 


Por supuesto, en el caso anterior, en realidad no se necesitaria un molde; sim- 
plemente se puede decir 200.f o 200.Of (en efecto, eso es tipicamente lo que el 
compilador hara para la expresion anterior). Los moldes normalmente se utilizan 
con variables, en lugar de con constantes. 


3.7.12. Los moldes explicitos de C++ 

Los moldes se deben utilizar con cuidado, porque lo que esta haciendo en reali¬ 
dad es decir al compilador «01vida la comprobacion de tipo - tratalo como si fuese 
de este otro tipo.» Esto significa, que esta introduciendo un agujero en el sistema de 
tipos de C++ y evitando que el compilador informe de que esta haciendo algo erro- 
neo con un tipo. Lo que es peor, el compilador lo cree implicitamente y no realiza 
ninguna otra comprobacion para buscar errores. Una vez ha comenzado a moldear, 
esta expuesto a todo tipo de problemas. De hecho, cualquier programa que utilice 
muchos moldes se debe revisar con detenimiento, no importa cuanto haya dado por 
sentado que simplemente «debe» hacerse de esta manera. En general, los moldes 
deben ser pocos y aislados para solucionar problemas espedficos. 

Una vez se ha entendido esto y se presente un programa con errores, la primera 
impresion puede que sea mirar los moldes como si fuesen los culpables. Pero, ^como 
encontrar los moldes estilo C? Son simplemente nombres de tipos entre parentesis, 
y si se empieza a buscar estas cosas descubrira que a menudo es dificil distinguirlos 
del resto del codigo. 

El C++ Estandar incluye una sintaxis explicita de molde que se puede utilizar 
para reemplazar completamente los moldes del estilo antiguo de C (por supuesto, los 
moldes de estilo C no se pueden prohibir sin romper el codigo, pero los escritores de 
compiladores pueden advertir facilmente acerca de los moldes antiguos). La sintaxis 
explicita de moldes esta pensada para que sea facil encontrarlos, tal como se puede 
observar por sus nombres: 

Los primeros tres moldes explicitos se describiran completamente en las siguien- 
tes secciones, mientras que los ultimos se explicaran despues de que haya aprendido 
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static_cast 

Para moldes que se comportan bien o 
razonablemente bien, incluyendo cosas 
que se podrian hacer sin un molde 
(como una conversion automatica de 
tipo). 

const_cast 

Para moldear const y/ o volatile 

reinterpret_cast 

Para moldear a un significado 
completamente diferente. La clave es 
que se necesitara volver a moldear al 
tipo original para poderlo usar con 
seguridad. El tipo al que moldee se 
usa tipicamente solo para jugar un 
poco o algun otro proposito 
misterioso. Este es el mas peligroso 
de todos los moldes. 

dynamic_cast 

Para realizar un downcasting seguro 
(este molde se describe en el Capitulo 
15). 


Cuadro 3.2: Moldes explicitos de C++ 


mas en el Capitulo 15. 

static_cast 

El static_cast se utiliza para todas las conversiones que estan bien defini- 
das. Esto incluye conversiones «seguras» que el compilador permitiria sin utilizar 
un molde, y conversiones menos seguras que estan sin embargo bien definidas. Los 
tipos de conversiones que cubre static_cast incluyen las conversiones tipicas sin 
molde, conversiones de estrechamiento (perdida de informacion), forzar una conver¬ 
sion de un void*, conversiones de tipo implicitas, y navegacion estatica de jerarquias 
de clases (ya que no se han visto aun clases ni herencias, este ultimo apartado se 
pospone hasta el Capitulo 15): 

//: C03:static_cast.cpp 
void func(int) {} 

int main() { 

int i = 0x7fff; // Max pos value = 32767 

long 1; 
float f; 

// (1) Typical castless conversions: 

1 = 1 ; 

f = i; 

// Also works: 

1 = static_cast<long> (i); 
f = static_cast<float> (i); 

// (2) Narrowing conversions: 
i = 1; // May lose digits 

i = f; // May lose info 

// Says "I know," eliminates warnings: 

i = static_cast<int> (1); 
i = static_cast<int> (f ); 
char c = static_cast<char> (i); 
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// (3) Forcing a conversion from void* : 

void* vp = &i; 

// Old way produces a dangerous conversion: 

float* fp = (float*) vp; 

// The new way is equally dangerous: 

fp = static_cast<float*> (vp) ; 

// (4) Implicit type conversions, normally 
// performed by the compiler: 

double d = 0.0; 

int x = d; // Automatic type conversion 
x = static_cast<int> (d); // More explicit 
func(d); // Automatic type conversion 
func (static_cast<int> (d)); // More explicit 
} ///:~ 


En la seccion (FIXME:xref:l), se pueden ver tipos de conversiones que eran usua- 
les en C, con o sin un molde. Promover un int a long o float no es un problema porque 
el ultimo puede albergar siempre cualquier valor que un int pueda contener. Aunque 
es innecesario, se puede utilizar static_cast para remarcar estas promociones. 

Se muestra en (2) como se convierte al reves. Aqui, se puede perder informa- 
cion porque un int no es tan «ancho» como un long o un float; no aloja numeros 
del mismo tamano. De cualquier modo, este tipo de conversion se llama conversion 
de estrechamiento. El compilador no impedira que ocurran, pero normalmente da- 
ra una advertencia. Se puede eliminar esta advertencia e indicar que realmente se 
pretendia esto utilizando un molde. 

Tomar el valor de un void* no esta permitido en C++ a menos que use un molde 
(al contrario de C), como se puede ver en (3). Esto es peligroso y requiere que los 
programadores sepan lo que estan haciendo. El static_cast, al menos, es mas 
facil de localizar que los moldes antiguos cuando se trata de cazar fallos. 

La seccion (FIXME:xref:4) del programa muestra las conversiones de tipo impli- 
citas que normalmente se realizan de manera automatica por el compilador. Son 
automaticas y no requieren molde, pero el utilizar static_cast acentua dicha ac- 
cion en caso de que se quiera reflejar claramente que esta ocurriendo, para poder 
localizarlo despues. 

const_cast 

Si quiere convertir de un const a un no-const o de un volatile a un no-v- 
olatile, se utiliza const_cast. Es la unica conversion permitida con const_c- 
ast; si esta involucrada alguna conversion adicional se debe hacer utilizando una 
expresion separada o se obtendra un error en tiempo de compilacion. 

//: C03:const_cast.cpp 

int main () { 

const int i = 0; 

int* j = (int*)&i; // Deprecated form 
j = const_cast<int*> (&i); // Preferred 
// Can't do simultaneous additional casting: 

//! long* 1 = const_cast<long*>(&i); // Error 

volatile int k = 0; 

int* u = const_cast<int*> (&k) ; 
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} ///:- 


Si toma la direccion de un objeto const, produce un puntero a const, este no 
se puede asignar a un puntero que no sea const sin un molde. El molde al estilo 
antiguo lo puede hacer, pero el const_cast es el mas apropiado en este caso. Lo 
mismo ocurre con volatile. 

reinterpret_cast 

Este es el menos seguro de los mecanismos de molde, y el mas susceptible de 
crear fallos. Un reinterpret_cast supone que un objeto es un patron de bits que 
se puede tratar (para algun oscuro proposito) como si fuese de un tipo totalmente 
distinto. Ese es el jugueteo de bits a bajo nivel por el cual C es famoso. Practicamente 
siempre necesitara hacer reinterpret_cast para volver al tipo original (o de lo 
contrario tratar a la variable como su tipo original) antes de hacer nada mas con ella. 

//: C03:reinterpret_cast.cpp 

#include <iostream> 

using namespace std; 
const int sz = 100; 

struct X { int a[sz]; }; 

void print (X* x) { 

for(int i = 0; i < sz; i++) 
cout << x->a[i] << ' '; 

cout << endl << "-" << endl; 

} 


int main () { 

X x; 

print(&x); 

int* xp = reinterpret_cast<int*> (&x); 

for(int* i = xp; i < xp + sz; i++) 

* i = 0 ; 

// Can't use xp as an X* at this point 
// unless you cast it back: 
print (reinterpret_cast<X*> (xp)); 

// In this example, you can also just use 
// the original identifier: 
print(&x); 

} ///:~ 


En este ejemplo, struct X contiene un array de int, pero cuando se crea uno 
en la pila como en X x, los valores de cada uno de los ints tienen basura (esto se 
demuestra utilizando la funcion print () para mostrar los contenidos de struct). 
Para inicializarlas, la direccion del X se toma y se moldea a un puntero int, que es 
luego iterado a traves del array para inicializar cada int a cero. Fijese como el limite 
superior de i se calcula «ahadiendo» sz a xp; el compilador sabe que lo que usted 
quiere realmente son las direcciones de sz mayores que xp y el realiza el calculo 
aritmetico por usted. FIXME(Comprobar lo que dice este parrafo de acuerdo con el 
codigo) 
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La idea del uso de reinterpret_cast es que cuando se utiliza, lo que se ob- 
tiene es tan extrano que no se puede utilizar para los propositos del tipo original, 
a menos que se vuelva a moldear. Aqui, vemos el molde otra vez a X* en la llama- 
da a print (), pero por supuesto, dado que tiene el identificador original tambien 
se puede utilizar. Pero xp solo es util como un inf', lo que es verdaderamente una 
«reinterpretacion» del X original. 

Un reinterpret_cast a menudo indica una programacion desaconsejada y/ o 
no portable, pero esta disponible si decide que lo necesita. 


3.7.13. sizeof - un operador en si mismo 

El operador sizeof es independiente porque satisface una necesidad inusual, 
sizeof proporciona informacion acerca de la cantidad de memoria ocupada por los 
elementos de datos. Como se ha indica do antes en este capitulo, sizeof indica el 
numero de bytes utilizado por cualquier variable particular. Tambien puede dar el 
tamano de un tipo de datos (sin necesidad de un nombre de variable): 

//: C03:sizeof.cpp 

#include <iostream> 

using namespace std; 
int main() { 

cout << "sizeof(double) = " << sizeof(double); 
cout << ", sizeof(char) = " << sizeof(char) ; 

} ///:- 


Por definicion, el sizeof de cualquier tipo de char (signed, unsigned o simple) 
es siempre uno, sin tener en cuenta que el almacenamiento subyacente para un char 
es realmente un byte. Para todos los demas tipos, el resultado es el tamano en bytes. 

Tenga en cuenta que sizeof es un operador, no una funcion. Si lo aplica a un 
tipo, se debe utilizar con la forma entre parentesis mostrada anteriormente, pero si 
se aplica a una variable se puede utilizar sin parentesis: 

//: C03:sizeofOperator.cpp 

int main() { 

int x; 

int i = sizeof x; 

} ///:~ 


sizeof tambien puede informar de los tamanos de tipos definidos por el usua- 
rio. Se utilizara mas adelante en el libro. 


3.7.14. La palabra reservada asm 

Este es un mecanismo de escape que permite escribir codigo ensamblador para 
el hardware dentro de un programa en C++. A menudo es capaz de referenciar va¬ 
riables C++ dentro del codigo ensamblador, lo que significa que se puede comunicar 
facilmente con el codigo C++ y limitar el codigo ensamblador a lo necesario para 
ajustes eficientes o para utilizar instrucciones especiales del procesador. La sintaxis 
exacta que se debe usar cuando se escribe en lenguaje ensamblador es dependiente 
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del compilador y se puede encontrar en la documentation del compilador. 


3.7.15. Operadores explfcitos 

Son palabras reservadas para los operadores logicos y binarios. Los programa- 
dores de fuera de los USA sin tedados con caracteres tales como &, I, ', y demas, 
estaban forzados a utilizar horribles trigrafos, que no solo eran insoportable de escri- 
bir, ademas eran diddles de leer. Esto se ha paliado en C++ con palabras reservadas 
adicionales: 


Palabra reservada 

Significado 

and 

&& ( «y» logica) 

or 

1 1 («o» logica) 

not 

! (negation logica) 

not_eq 

!= (no-equivalencia logica) 

bitand 

& (and para bits) 

and_eq 

&= (asignacion-and para bits) 

bitor 

1 (or para bits) 

or_eq 

!= (asignacion-or para bits) 

xor 

~ («o» exclusiva para bits) 

xor_equ 

"= (asignacion xor para bits) 

compl 

~ (complemento binario) 


Cuadro 3.3: Nuevas palabras reservadas para operadores booleanos 
Si el compilador obedece al Estandar C++, soportara estas palabras reservadas. 


3.8. Creacion de tipos compuestos 

Los tipos de datos fundamentales y sus variantes son esenciales, pero mas bien 
primitivos. C y C++ incorporan herramientas que permiten construir tipos de da¬ 
tos mas sofisticados a partir de los tipos de datos fundamentales. Como se vera, el 
mas importante de estos es struct, que es el fundamento para las class en C++. 
Sin embargo, la manera mas simple de crear tipos mas sofisticados es simplemente 
poniendo un alias a otro nombre mediante typedef. 


3.8.1. Creacion de alias usando typedef 

Esta palabra reservada promete mas de lo que da: typedef sugiere «definicion 
de tipo» cuando «alias» habria sido probablemente una description mas acertada, 
ya que eso es lo que hace realmente. La sintaxis es: 

typedef descripcion-de-tipo-existente nombre-alias 

La gente a menudo utiliza typedef cuando los tipos de datos se vuelven com- 
plicados, simplemente para evitar escribir mas de lo necesario. A continuation, una 
forma comun de utilizar typedef: 

typedef unsigned long ulong; 


Ahora si pone ulong, el compilador sabe que se esta refiriendo a unsigned long. 
Puede pensar que esto se puede lograr facilmente utilizando sustitucion en el pre- 




'Volumenl" — 2012/1/12 — 13:52 — page 110 — #148 


Capitulo 3. C en C++ 


procesador, pero hay situaciones en las cuales el compilador debe estar advertido de 
que esta tratando un nombre como si fuese un tipo, y por eso typedef es esencial. 

int* x, y; 


Esto genera en realidad un int* que es x, y un int (no un int*) que es y. Esto 
significa que el * anade a la derecha, no a la izquierda. Pero, si utiliza un typedef: 

typedef int* IntPtr; 

IntPtr x, y; 


Entonces ambos, x e y son del tipo int*. 

Se puede discutir sobre ello y decir que es mas explicito y por consiguiente mas 
legible evitar typedefs para los tipos primitivos, y de hecho los programas se vuel- 
ven dificiles de leer cuando se utilizan demasiados typedefs. De todos modos, los 
typedefs se vuelven especialmente importantes en C cuando se utilizan con str¬ 
uct. 


3.8.2. Usar struct para combinar variables 

Un struct es una manera de juntar un grupo de variables en una estructura. 
Cuando se crea un struct, se pueden crear varias instancias de este «nuevo» tipo 
de variable que ha inventado. Por ejemplo: 

//: C03:SimpleStruct.cpp 

struct Structurel { 

char c; 
int i; 
float f; 
double d; 

} ; 


int main ( 

) { 

struct 

Structurel si, s2; 

si. c = 

'a'; // Select an element 

si. i = 

l; 

sl.f = 

3.14; 

si. d = 

0.00093; 

s2 . c = 

'a' ; 

s2 . i = 

l; 

s2 . f = 

3.14; 

s2 . d = 

} ///:- 

0.00093; 


La declaracion de struct debe acabar con una Have. En main (), se crean dos 
instancias de Structurel: si y s2. Cada una de ellas tiene su version propia y sepa- 
rada de c, I, f y d. De modo que si y s2 representan bloques de variables com- 
pletamente independientes. Para seleccionar uno de estos elementos dentro de si o 
s2, se utiliza un ., sintaxis que se ha visto en el capitulo previo cuando se utilizaban 
objetos class de C++ - ya que las clases surgian de structs, de ahi proviene esta 
sintaxis. 
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Una cosa a tener en cuenta es la torpeza de usar Structurel (como salta a la vista, 
eso solo se requiere en C, y no en C++). En C, no se puede poner Structurel cuando 
se definen variables, se debe poner struct Structurel. Aqui es donde typedef se 
vuelve especialmente util en C: 

//: C03 :SimpleStruct2.cpp 
// Using typedef with struct 

typedef struct { 
char c; 
int i; 
float f; 
double d; 

} Structure2; 

int main() { 

Structure2 si, s2; 
si.c = 'a'; 
s 1. i = 1 ; 
sl.f = 3.14; 
sl.d = 0.00093; 
s2 . c = ' a' ; 
s2.i = 1; 
s2.f = 3.14; 
s2.d = 0.00093; 

} ///:-• 


Usando typedef de este modo, se puede simular (en C; intentar eliminar el t- 
ypedef para C++) que Structure2 es un tipo predefinido, como int o float, cuando 
define s 1 y s 2 (pero se ha de tener en cuenta de que solo tiene informacion - carac- 
teristicas - y no incluye comportamiento, que es lo que se obtiene con objetos reales 
en C++). Observe que el struct se ha declarado al principio, porque el objetivo es 
crear el typedef. Sin embargo, hay veces en las que seria necesario referirse a st¬ 
ruct durante su definicion. En esos casos, se puede repetir el nombre del struct 
como tal y como typedef. 

//: C03:SelfReferential.cpp 
// Allowing a struct to refer to itself 

typedef struct SelfReferential { 

int i; 

SelfReferential* sr; // Head spinning yet? 

} SelfReferential; 

int main () { 

SelfReferential srl, sr2; 

srl.sr = &sr2; 

sr2.sr = &srl; 

srl.i = 47; 

sr2.i = 1024; 

} /// : ~ 


Si lo observa detenidamente, puede ver que srl y sr2 apuntan el uno al otro, 
guardando cada uno una parte de la informacion. 
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En realidad, el nombre struct no tiene que ser lo mismo que el nombre type- 
def, pero normalmente se hace de esta manera ya que tiende a simplificar las cosas. 

Punteros y estructuras 

En los ejemplos anteriores, todos los structs se manipulan como objetos. Sin 
embargo, como cualquier bloque de memoria, se puede obtener la direccion de un 
objeto struct (tal como se ha visto en SelfReferential. cpp). Para seleccionar 
los elementos de un objeto struct en particular, se utiliza un ., como se ha visto 
anteriormente. No obstante, si tiene un puntero a un objeto struct, debe seleccionar 
un elemento de dicho objeto utilizando un operador diferente: el ->. A continuacion, 
un ejemplo: 

//: C03:SimpleStruct3.cpp 
// Using pointers to structs 

typedef struct Structure3 { 
char c; 
int i; 
float f; 
double d; 

} Structure3; 

int main() { 

Structure3 si, s2; 

Structure3* sp = &sl; 
sp->c = ' a' ; 
sp->i = 1; 
sp->f = 3.14; 
sp->d = 0.00093; 

sp = &s2; // Point to a different struct object 

sp->c = ' a' ; 

sp->i = 1; 

sp->f = 3.14; 

sp->d = 0.00093; 

} ///:~ 


En main (), el puntero sp esta apuntando inicialmente a si, y los miembros de 
s 1 se inicializan seleccionandolos con el -> (y se utiliza este mismo operador para 
leerlos). Pero luego sp apunta a s2, y esas variables se inicializan del mismo modo. 
Como puede ver, otro beneficio en el uso de punteros es que pueden ser redirigidos 
dinamicamente para apuntar a objetos diferentes, eso proporciona mas flexibilidad 
a sus programas, tal como vera. 

De momento, es todo lo que debe saber sobre struct, pero se sentira mucho 
mas comodo con ellos (y especialmente con sus sucesores mas potentes, las clases) a 
medida que progrese en este libro. 


3.8.3. Programas mas claros gracias a enum 

Un tipo de datos enumerado es una manera de asociar nombres a numeros, y 
por consiguiente de ofrecer mas significado a alguien que lea el codigo. La palabra 
reservada enum (de C) enumera automaticamente cualquier lista de identificadores 
que se le pase, asignandoles valores de 0,1, 2, etc. Se pueden declarar variables en¬ 
um (que se representan siempre como valores enteros). La declaracion de un enum se 
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parece a la declaration de un struct. 

Un tipo de datos enumerado es util cuando se quiere poder seguir la pista de 
alguna caracterlstica: 

//: C03:Enum.cpp 
// Keeping track of shapes 

enum ShapeType { 
circle, 
square, 
rectangle 

}; // Must end with a semicolon like a struct 

int main() { 

ShapeType shape = circle; 

// Activities here.... 

// Now do something based on what the shape is: 
switch (shape) { 

case circle: /* circle stuff */ break; 
case square: /* square stuff */ break; 
case rectangle: /* rectangle stuff */ break; 


} ///:~ 


shape es una variable del tipo de datos enumerado ShapeType, y su valor se 
compara con el valor en la enumeration. Ya que shape es realmente un int, puede 
albergar cualquier valor que corresponda a int (incluyendo un numero negativo). 
Tambien se puede comparar una variable int con un valor de una enumeration. 

Se ha de tener en cuenta que el ejemplo anterior de intercambiar los tipos tiende 
a ser una manera problematica de programar. C++ tiene un modo mucho mejor de 
codificar este tipo de cosas, cuya explication se pospondra para mucho mas adelante 
en este libro. 

Si el modo en que el compilador asigna los valores no es de su agrado, puede 
hacerlo manualmente, como sigue: 

enum ShapeType { 

circle = 10, square = 20, rectangle = 50 

} ; 


Si da valores a algunos nombres y a otros no, el compilador utilizara el siguiente 
valor entero. Por ejemplo, 

enum snap { crackle = 25, pop }; 


El compilador le da a pop el valor 2 6. 

Es facil comprobar que el codigo es mas legible cuando se utilizan tipos de datos 
enumerados. No obstante, en cierto grado esto sigue siendo un intento (en C) de 
lograr las cosas que se pueden lograr con una class en C++, y por eso vera que 
enum se utiliza menos en C++. 
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Comprobacion de tipos para enumerados 

Las enumeraciones en C son bastante primitivas, simplemente asocian valores 
enteros a nombres, pero no aportan comprobacion de tipos. En C++, como era de 
esperar a estas alturas, el concepto de tipos es fundamental, y eso se cumple con 
las enumeraciones. Cuando crea una enumeracion nombrada, crea efectivamente un 
nuevo tipo, tal como se hace con una clase: El nombre de la enumeracion se convierte 
en una palabra reservada durante esa unidad de traduccion. 

Ademas, hay una comprobacion de tipos mas estricta para la enumeracion en 
C++ que en C. En particular, resulta evidente si tiene una instancia de la enumeracion 
color llamada a. En C puede decir a++, pero en C++ no es posible. Eso se debe a que 
el incrementar una enumeracion se realizan dos conversiones de tipo, una de ellas es 
legal en C++ y la otra no. Primero, el valor de la enumeracion se convierte del tipo 
color a int, luego el valor se incrementa, y finalmente el int se vuelve a convertir a 
tipo color. En C++ esto no esta permitido, porque color es un tipo diferente de int. 
Eso tiene sentido, porque ^como saber si el incremento de blue siquiera estara en la 
lista de colores? Si quiere poder incrementar un color, deberia ser una clase (con una 
operacion de incremento) y no un enum, porque en la clase se puede hacer de modo 
que sea mucho mas seguro. Siempre que escriba codigo que asuma una conversion 
implicita a un tipo enum, el compilador alertara de que se trata de una actividad 
inherentemente peligrosa. 

Las uniones (descriptas a continuacion) tienen una comprobacion adicional de 
tipo similar en C++. 



3.8.4. Como ahorrar memoria con union 

A veces un programa manejara diferentes tipos de datos utilizando la misma 
variable. En esta situacion, se tienen dos elecciones: se puede crear un struct que 
contenga todos los posibles tipos que se puedan necesitar almacenar, o se puede 
utilizar una union. Una union amontona toda la informacion en un unico espacio; 
calcula la cantidad de espacio necesaria para el elemento mas grande, y hace de ese 
sea el tamano de la union. Utilice la union para ahorrar memoria. 

Cuando se coloca un valor en una union, el valor siempre comienza en el mismo 
sitio al principio de la union, pero solo utiliza el espacio necesario. Por eso, se crea 
una «super-variable» capaz de alojar cualquiera de las variables de la union. Las 
direcciones de todas las variables de la union son la misma (en una clase o struct, 
las direcciones son diferentes). 

A continuacion, un uso simple de una union. Intente eliminar varios elementos 
y observe que efecto tiene en el tamano de la union. Frjese que no tiene sentido 
declarar mas de una instancia de un solo tipo de datos en una union (a menos que 
quiera darle un nombre distinto). 

//: C03:Union.cpp 

// The size and simple use of a union 

#include <iostream> 

using namespace std; 

union Packed { // Declaration similar to a class 

char i; 
short j; 
int k; 
long 1; 
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float f; 
double d; 

// The union will be the size of a 
// double, since that's the largest element 
}; // Semicolon ends a union, like a struct 

int main() { 

cout << "sizeof (Packed) = " 

<< sizeof (Packed) << endl; 

Packed x; 
x.i = ' c' ; 

cout << x.i << endl; 
x.d = 3.14159; 
cout << x.d << endl; 

} ///:~ 


El compilador realiza la asignacion apropiada para el miembro de la union selec- 
donado. 

Una vez que se realice una asignacion, al compilador le da igual lo que se haga 
con la union. En el ejemplo anterior, se puede asignar un valor en coma-flotante a x: 

x.f = 2.222; 


Y luego enviarlo a la salida como si fuese un int: 

cout << x.i; 


Eso produciria basura. 


3.8.5. Arrays 

Los vectores son un tipo compuesto porque permiten agrupar muchas variables, 
una a continuation de la otra, bajo un identificador unico. Si dice: 

int a [ 10]; 

Se crea espacio para 10 variables int colocadas una despues de la otra, pero sin 
identificadores unicos para cada variable. En su lugar, todas estan englobadas por el 
nombre a. 

Para acceder a cualquiera de los elementos del vector, se utiliza la misma sintaxis 
de corchetes que se utiliza para definir el vector: 

a[5] = 47; 

Sin embargo, debe recordar que aunque el tamano de a es 10, se seleccionan los 
elementos del vector comenzando por cero (esto se llama a veces indexado a cero i , de 
modo que solo se pueden seleccionar los elementos del vector de 0 a 9, como sigue: 


4 (N. de T.) zero indexing 
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//: C03:Arrays.cpp 

#include <iostream> 

using namespace std; 

int raain() { 
int a[10] ; 

for(int i = 0; i < 10; i++) { 

a [i] = i * 10; 

cout << "a[" << i << "] = " << a[i] << endl; 

} 

} ///:~ 


Los accesos a vectores son extremadamente rapidos, Sin embargo, si se indexa 
mas alia del final del vector, no hay ninguna red de seguridad - se entrara en otras 
variables. La otra desventaja es que se debe definir el tamano del vector en tiempo 
de compilacion; si se quiere cambiar el tamano en tiempo de ejecucion no se puede 
hacer con la sintaxis anterior (C tiene una manera de crear un vector dinamicamente, 
pero es significativamente mas sucia). El vector de C++ presentado en el capitulo 
anterior, proporciona un objeto parecido al vector que se redimensiona automatica- 
mente , de modo que es una solucion mucho mejor si el tamano del vector no puede 
conocer en tiempo de compilacion. 

Se puede hacer un vector de cualquier tipo, incluso de structs: 

//: C03:StructArray.cpp 
// An array of struct 

typedef struct { 

int i , j , k ; 

} ThreeDpoint; 

int main () { 

ThreeDpoint p[10]; 
for(int i = 0; i < 10; i++) { 

p [ i ] . i = i + 1; 

p [ i ] . j = i + 2; 

p [ i ] . k = i + 3 ; 

} 

} ///:- 


Fijese como el identificador de struct i es independiente del i del bucle for. 

Para comprobar que cada elemento del vector es contiguo con el siguiente, puede 
imprimir la direccion de la siguiente manera: 

//: C03:ArrayAddresses.cpp 

#include <iostream> 

using namespace std; 

int main() { 

int a[10]; 

cout << "sizeof(int) = "<< sizeof(int) << endl; 
for(int i = 0; i < 10; i++) 
cout << "&a[" << i << "] = " 



'Volumenl" — 2012/1/12 — 13:52 — page 117 — #155 


3.8. Creadon de tipos compuestos 


<< (long) &a [i] << endl; 

} ///:- 


Cuando se ejecuta este programa, se ve que cada elemento esta separado por el 
tamano de un int del anterior. Esto significa, que estan colocados uno a continuacion 
del otro. 


Punteros y arrays 

El identificador de un vector es diferente de los identificadores de las variables 
comunes. Un identificador de un vector no es un lvalue', no se le puede asignar nada. 
En realidad es FIXME:gancho dentro de la sintaxis de corchetes, y cuando se usa el 
nombre de un vector, sin los corchetes, lo que se obtiene es la direccion inicial del 
vector: 

//: C03:Arrayldentifier.cpp 

#include <iostream> 

using namespace std; 

int main() { 

int a[10]; 

cout << "a = " << a << endl; 

cout << "&a[0] =" << &a[0] << endl; 

} /// : ~ 


Cuando se ejecuta este programa, se ve que las dos direcciones (que se imprimen 
en hexadecimal, ya que no se moldea a long) son las misma. 

De modo que una manera de ver el identificador de un vector es como un puntero 
de solo lectura al principio de este. Y aunque no se pueda hacer que el identificador 
del vector apunte a cualquier otro sitio, se puede crear otro puntero y utilizarlo para 
moverse dentro del vector. De hecho, la sintaxis de corchetes tambien funciona con 
punteros convencionales: 

//: C03:PointersAndBrackets.cpp 
int main() { 

int a[10]; 
int* ip = a; 

for(int i = 0; i < 10; i++) 
ip[i] = i * 10; 

} ///:~ 


El hecho de que el nombre de un vector produzca su direccion de inicio resulta 
bastante importante cuando hay que pasar un vector a una funcion. Si declara un 
vector como un argumento de una funcion, lo que realmente esta declarando es un 
puntero. De modo que en el siguiente ejemplo, funl () y func2 () tienen la misma 
lista de argumentos: 

//; C03:ArrayArguments.cpp 

#include <iostream> 

#include <string> 
using namespace std; 
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void fund (int a[], int size) { 
for(int i = 0; i < size; i++) 
a[i] = i * i - i; 

} 


void func2 (int* a, int size) { 
for(int i = 0; i < size; i++) 
a [ i ] = i * i + i; 

} 

void print (int a[], string name, int size) { 
for(int i = 0; i < size; i++) 

cout << name << "[" << i << "] = " 

<< a[i] << endl; 

} 


int main() { 

int a[5], b[5]; 

// Probably garbage values: 


print (a, a , 
print (b, "b", 

// Initialize 
fund (a, 5) ; 
fund (b, 5) ; 
print(a, "a", 

print(b, "b", 

// Notice the 
func2(a, 5); 
func2 (b, 5); 
print(a, "a", 

print (b, "b", 

} ///:~ 


5) ; 

5) ; 

the arrays: 


5) ; 

5) ; 

arrays are always 


5) ; 
5) ; 


modified: 


A pesar de que fund () y func2 () declaran sus argumentos de distinta forma, 
el uso es el mismo dentro de la funcion. Hay otros hechos que revela este ejemplo: 
los vectores no se pueden pasados por valor 5 , es decir, que nunca se puede obtener 
automaticamente una copia local del vector que se pasa a una funcion. Por eso, cuan- 
do se modifica un vector, siempre se esta modificando el objeto externo. Eso puede 
resultar un poco confuso al principio, si lo que se espera es el paso-por-valor como 
en los argumentos ordinarios. 

Frjese que print () utiliza la sintaxis de corchetes para los argumentos de tipo 
vector. Aunque la sintaxis de puntero y la sintaxis de corchetes efectivamente es la 
mismo cuando se estan pasando vectores como argumentos, la sintaxis de corchetes 
deja mas clara al lector que se pretende enfatizar que dicho argumento es un vector. 

Observe tambien que el argumento size se pasa en cada caso. La direccion no 
es suficiente informacion al pasar un vector; siempre se debe ser posible obtener el 
tamano del vector dentro de la funcion, de manera que no se saiga de los limites de 

5 A menos que tome la siguiente aproximacion estricta: «todos los argumentos pasado en C/C++ son 
por valor, y el «valor» de un vector es el producido por su identificador: su direction*. Eso puede parecer 
correcto desde el punto de vista del lenguaje ensamblador, pero yo no creo que ayude cuando se trabaja 
con conceptos de alto nivel. La inclusion de referencias en C++ hace que el argumento «todo se pasa por 
valor* sea mas confuso, hasta el punto de que siento que es mas adecuado pensar en terminos de «paso 
por valor* vs «paso por direccion*. 
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dicho vector. 

Los vectores pueden ser de cualquier tipo, incluyendo vectores de punteros. De 
hecho, cuando se quieren pasar argumentos de tipo linea de comandos dentro del 
programa, C y C++ tienen una lista de argumentos especial para main (), que tiene 
el siguiente aspecto: 

int main (int argc, char* argv[]) { // ... 

El primer argumento es el numero de elementos en el vector, que es el segun- 
do argumento. El segundo argumento es siempre un vector de char*', porque los 
argumentos se pasan desde la linea de comandos como vectores de caracteres (y re- 
cuerde, un vector solo se puede pasar como un puntero). Cada bloque de caracteres 
delimitado por un espacio en bianco en la linea de comandos se aloja en un elemento 
separado en el vector. El siguiente programa imprime todos los argumentos de linea 
de comandos recorriendo el vector: 

//: C03:CommandLineArgs.cpp 

#include <iostream> 

using namespace std; 

int main (int argc, char* argv[]) { 

cout << "argc = " << argc << endl; 
for(int i = 0; i < argc; i++) 
cout << "argv[" << i << "] = " 

<< argvfi] << endl; 

1 // / : ~ 


Observe que argv[0] es la ruta y el nombre del programa en si mismo. Eso 
permite al programa descubrir informacion de si mismo. Tambien anade un argu¬ 
mento mas al vector de argumentos del programa, de modo que un error comun al 
recoger argumentos de linea de comandos es tomar argv[0] como si fuera el primer 
argumento. 

No es obligatorio utilizar argc y argv como identificadores de los parametros 
de main (); estos identificadores son solo convenciones (pero puede confundir al 
lector si no se respeta). Tambien, hay un modo alternative de declarar argv: 

int main(int argc, char** argv) { // ... 

Las dos formas son equivalentes, pero la version utilizada en este libro es la mas 
intuitiva al leer el codigo, ya que dice, directamente, «Esto es un vector de punteros 
a caracter». 

Todo lo que se obtiene de la linea de comandos son vectores de caracteres; si 
quiere tratar un argumento como algun otro tipo, ha de convertirlos dentro del pro¬ 
grama. Para facilitar la conversion a numeros, hay algunas funciones en la libreria 
de C Estandar, declaradas en <cstdlib>. Las mas faciles de utilizar son atoi (), 
atol () , y at of () para convertir un vector de caracteres ASCII a int, long y dou¬ 
ble, respectivamente. A continuation, un ejemplo utilizando atoi () (las otras dos 
funciones se invocan del mismo modo): 

//: C03:ArgsToInts.cpp 

// Converting command-line arguments to ints 
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#include <iostream> 

#include <cstdlib> 
using namespace std; 

int main (int argc, char* argv[]) { 

for(int i = 1; i < argc; i++) 
cout << atoi(argv[i]) << endl; 

} ///:~ 


En este programa, se puede poner cualquier niimero de argumentos en la linea 
de comandos. Fijese que el bucle for comienza en el valor 1 para saltar el nombre 
del programa en argv [ 0 ]. Tambien, si se pone un numero decimal que contenga 
un punto decimal en la linea de comandos, atoi () solo toma los digitos hasta el 
punto decimal. Si pone valores no numericos en la linea de comandos, atoi () los 
devuelve como ceros. 

El formato de punto flotante 

La funcion printBinary () presentada anteriormente en este capitulo es util 
para indagar en la estructura interna de varios tipos de datos. El mas interesante 
es el formato de punto-flotante que permite a C y C++ almacenar numeros que re- 
presentan valores muy grandes y muy pequenos en un espacio limitado. Aunque 
los detalles no se pueden exponer completamente expuestos, los bits dentro de los 
floats y doubles estan divididos en tres regiones: el exponente, la mantisa, y el bit 
de signo; asi almacena los valores utilizando notacion cientifica. El siguiente progra¬ 
ma permite jugar con ello imprimiendo los patrones binarios de varios numeros en 
punto-flotante de modo que usted mismo pueda deducir el esquema del formato de 
punto flotante de su compilador (normalmente es el estandar IEEE para numeros en 
punto-flotante, pero su compilador puede no seguirlo): 

//: C03:FloatingAsBinary.cpp 
//{L} printBinary 
//{T} 3.14159 

#include "printBinary.h" 

#include <cstdlib> 

#include <iostream> 

using namespace std; 

int main (int argc, char* argv[]) { 

if (argc != 2) { 

cout << "Must provide a number" << endl; 
exit (1); 

} 

double d = atof(argv[1]); 

unsigned char* cp = 

reinterpret_cast<unsigned char*> (&d); 
for(int i = sizeof(double) -1; i >= 0 ; i -= 2){ 
printBinary(cp[i-1]) ; 
printBinary(cp[i] ) ; 

} 


} ///:- 
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Primero, el programa garantiza que se le haya pasado un argumento compro- 
bando el valor de argc, que vale dos si hay un solo argumento (es uno si no hay 
argumentos, ya que el nombre del programa siempre es el primer elemento de a- 
rgv). Si eso falla, imprime un mensaje e invoca la funcion exit () de la libreria 
Estandar de C para finalizar el programa. 

El programa toma el argumento de la linea de comandos y convierte los caracte- 
res a double utilizando at of (). Luego el double se trata como un vector de bytes 
tomando la direccion y moldeandola a un unsigned char*'. Para cada uno de estos 
bytes se llama a printBinary () para mostrarlos. 

Este ejemplo se ha creado para imprimir los bytes en un orden tal que el bit de 
signo aparece al principio - en mi maquina. En otras maquinas puede ser diferente, 
por lo que puede querer re-organizar el modo en que se imprimen los bytes. Tambien 
deberia tener cuidado porque los formatos en punto-flotante no son tan triviales de 
entender; por ejemplo, el exponente y la mantisa no se alinean generalmente entre 
los limites de los bytes, en su lugar un numero de bits se reserva para cada uno y 
se empaquetan en la memoria tan apretados como se pueda. Para ver lo que esta 
pasando, necesitaria averiguar el tamano de cada parte del numero (los bit de signo 
siempre son de un bit, pero los exponentes y las mantisas pueden ser de diferentes 
tamanos) e imprimir separados los bits de cada parte. 

Aritmetica de punteros 

Si todo lo que se pudiese hacer con un puntero que apunta a un vector fuese 
tratarlo como si fuera un alias para ese vector, los punteros a vectores no tendrian 
mucho interes. Sin embargo, los punteros son mucho mas flexibles que eso, ya que se 
pueden modificar para apuntar a cualquier otro sitio (pero recuerde, el identificador 
del vector no se puede modificar para apuntar a cualquier otro sitio). 

La aritmetica de punteros se refiere a la aplicacion de alguno de los operadores 
aritmeticos a los punteros. Las razon por la cual la aritmetica de punteros es un tema 
separado de la aritmetica ordinaria es que los punteros deben ajustarse a clausulas 
especiales de modo que se comporten apropiadamente. Por ejemplo, un operador 
comun para utilizar con punteros es ++, lo que "ahade uno al puntero." Lo que de 
hecho significa esto es que el puntero se cambia para moverse al "siguiente valor," 
Lo que sea que ello signifique. A continuacion, un ejemplo: 

//: C03:PointerIncrement.cpp 

#include <iostream> 

using namespace std; 

int main() { 

int i [ 10] ; 

double d[10]; 

int* ip = i; 


double* 

dp = d; 





cout << 

ip++; 

"ip = " 

<< 

(long) ip 

<< 

endl 

cout << 

"ip = " 

<< 

(long) ip 

<< 

endl 

cout << 
dp++; 

"dp = " 

<< 

(long) dp 

<< 

endl 

cout << 

///:~ 

"dp = " 

<< 

(long) dp 

<< 

endl 
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Para una ejecucion en mi maquina, la salida es: 

ip = 6684124 
ip = 6684128 
dp = 6684044 
dp = 6684052 


Lo interesante aqui es que aunque la operacion ++ parece la misma tanto para el 
int* como para el double*, se puede comprobar que el puntero de int* ha cambiado 
4 bytes mientras que para el double* ha cambiado 8. No es coincidencia, que estos 
sean los tamanos de int y double en esta maquina. Y ese es el truco de la aritmetica 
de punteros: el compilador calcula la cantidad apropiada para cambiar el puntero de 
modo que apunte al siguiente elemento en el vector (la aritmetica de punteros solo 
tiene sentido dentro de los vectores). Esto funciona incluso con vectores de st ructs: 

//: C03:PointerIncrement2.cpp 

#include <iostream> 

using namespace std; 

typedef struct { 
char c; 
short s; 
int i; 
long 1; 
float f; 
double d; 
long double Id; 

} Primitives; 

int main () { 

Primitives p[10]; 

Primitives* pp = p; 

cout << "sizeof(Primitives) = " 

<< sizeof(Primitives) << endl; 
cout << "pp = " << (long)pp << endl; 

pp++; 

cout << "pp = " << (long)pp << endl; 

} ///:- 


La salida en esta maquina es: 

sizeof(Primitives) = 40 
pp = 6683764 
pp = 6683804 


Como puede ver, el compilador tambien hace lo adecuado para punteros a str- 

ucts (y con class y union). 

La aritmetica de punteros tambien funciona con los operadores —, + y pero 
los dos ultimos estan limitados: no se puede sumar dos punteros, y si se restan pun¬ 
teros el resultado es el numero de elementos entre los dos punteros. Sin embargo, 
se puede sumar o restar un valor entero y un puntero. A continuacion, un ejemplo 
demostrando el uso de la aritmetica de punteros: 
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//: C03:PointerArithmetic.cpp 

#include <iostream> 

using namespace std; 

#define P (EX) cout << #EX << " << EX << endl; 

int main() { 

int a[10] ; 

for(int i = 0; i < 10; i++) 

a[i] = i; // Give it index values 

int* ip = a; 

P(*ip); 

P(*++ip); 

P (* (ip + 5) ) ; 
int* ip2 = ip + 5; 

P(*ip2); 

P(*(ip2 - 4) ) ; 

P(*—ip2); 

P(ip2 - ip); // Yields number of elements 
} ///:~ 


Comienza con otra macro, pero esta utiliza una caracteristica del preprocesador 
llamada stringizing (implementada mediante el signo # antes de una expresion) que 
toma cualquier expresion y la convierte a un vector de caracteres. Esto es bastante 
conveniente, ya que permite imprimir la expresion seguida de dos puntos y del valor 
de la expresion. En main ( ) puede ver lo util que resulta este atajo. 

Aunque tan to la version prefijo como sufijo de ++ y — son validas para los pun- 
teros, en este ejemplo solo se utilizan las versiones prefijo porque se aplican antes 
de referenciar el puntero en las expresiones anteriores, de modo que permite ver los 
efectos en las operaciones. Observe que se han sumado y restado valores enteros; si 
se combinasen de este modo dos punteros, el compilador no lo permitiria. 

Aqui se ve la salida del programa anterior: 

*ip: 0 
*++ip: 1 

*(ip + 5) : 6 
*ip2: 6 

*(ip2 - 4) : 2 
* — ip2 : 5 


En todos los casos, el resultado de la aritmetica de punteros es que el puntero 
se ajusta para apuntar al «sitio corrector basandose en el tamano del tipo de los 
elementos a los que esta apuntado. 

Si la aritmetica de punteros le sobrepasa un poco al principio, no tiene porque 
preocuparse. La mayoria de las veces solo la necesitara para crear vectores e indexar- 
los con [ ], y normalmente la aritmetica de punteros mas sofisticada que necesitara 
es ++ y — .La aritmetica de punteros generalmente esta reservada para programas 
mas complejos e ingeniosos, y muchos de los contenedores en la libreria de Estandar 
C++ esconden muchos de estos inteligentes detalles, por lo que no tiene que preocu¬ 
parse de ellos. 
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3.9. Consejos para depuracion 

En un entorno ideal, habra un depurador excelente disponible que hara que el 
comportamiento de su programa sea transparente y podra descubrir cualquier error 
rapidamente. Sin embargo, muchos depuradores tienen puntos debiles, y eso puede 
requerir tenga que anadir trozos de codigo a su programa que le ayuden a entender 
que esta pasando. Ademas, puede que para la plataforma para la que este desarro- 
llando (por ejemplo en sistemas empotrados, con lo que yo tuve que tratar durante 
mis anos de formacion) no haya ningun depurador disponible, y quiza tenga una re- 
alimentacion muy limitada (por ejemplo, un display de LEDs de una linea). En esos 
casos debe ser creativo a la hora de descubrir y representar informacion acerca de la 
ejecucion de su programa. Esta seccion sugiere algunas tecnicas para conseguirlo. 


3.9.1. Banderas para depuracion 

Si coloca el codigo de depuracion mezclado con un programa, tendra problemas. 
Empezara a tener demasiada informacion, que hara que los errores sean dificiles de 
aislar. Cuando cree que ha encontrado el error empieza a quitar el codigo de depu¬ 
racion, solo para darse cuenta que necesita ponerlo de nuevo. Puede resolver estos 
problemas con dos tipos de banderas: banderas de depuracion del preprocesador y 
banderas de depuracion en ejecucion. 

Banderas de depuracion para el preprocesador 

Usando el preprocesador para definir (con #define) una o mas banderas de 
depuracion (preferiblemente en un fichero de cabecera), puede probar una bande- 
ra usando una sentencia #ifdef e incluir condicionalmente codigo de depuracion. 
Cuando crea que la depuracion ha terminado, simplemente utilice #undef la ban- 
dera y el codigo quedara eliminado automaticamente (y reducira el tamano y sobre- 
carga del fichero ejecutable). 

Es mejor decidir los nombres de las banderas de depuracion antes de empezar a 
contruir el proyecto para que los nombres sean consistentes. Las banderas del pre¬ 
procesador tradicionalmente se distinguen de las variables porque se escriben todo 
en mayusculas. Un nombre habitual es simplemente DEBUG (pero tenga cuidado de 
no usar NDEBUG, que esta reservado en C). La secuencia de sentencias podrias ser: 

#define DEBUG // Probably in a header file 

II... 

#ifdef DEBUG // Check to see if flag is defined 
/* debugging code here */ 

#endif // DEBUG 

La mayoria de las implementaciones de C y C++ tambien le permitiran definir 
y eliminar banderas (con #define y #undef) desde linea de comandos, y de ese 
modo puede recompilar codigo e insertar informacion de depuracion con un unico 
comando (preferiblemente con un makefile, una herramienta que sera descrita en 
breve). Compruebe la documentation de su entorno si necesita mas detalles. 

Banderas para depuracion en tiempo de ejecucion 

En algunas situaciones es mas conveniente activar y desactivar las banderas de 
depuracion durante la ejecucion del programa, especialmente cuando el programa 
se ejecuta usando la linea de comandos. Con programas grandes resulta pesado re- 



'Volumenl" — 2012/1/12 — 13:52 — page 125 — #163 


3.9. Consejos para depuracion 


compilar solo para insertar codigo de depuracion. 

Para activar y desactivar codigo de depuracion dinamicamente cree banderas 
booleanas. 

//: C03:DynamicDebugFlags.cpp 

#include <iostream> 

#include <string> 
using namespace std; 

// Debug flags aren't necessarily global: 

bool debug = false; 

int main (int argc, char* argv[]) { 

for(int i = 0; i < argc; i++) 

if (string(argv[i]) == "--debug=on") 
debug = true; 
bool go = true; 
while (go) { 
if (debug) { 

// Debugging code here 

cout << "Debugger is now on!" << endl; 

} else { 

cout << "Debugger is now off." << endl; 

} 

cout << "Turn debugger [on/off/quit]: "; 

string reply; 
cin >> reply; 

if (reply == "on") debug = true; // Turn it on 
if (reply == "off") debug = false; // Off 
if (reply == "quit") break; // Out of 'while' 

} 

} // / : ~ 


Este programa sigue permitiendole activar y desactivar la bandera de depuracion 
hasta que escriba quit para indicarle que quiere salir. Fijese que es necesario escribir 
palabras completas, no solo letras (puede abreviarlo a letras si lo desea). Opcional- 
mente, tambien se puede usar un argumento en linea de comandos para comenzar 
la depuracion - este argumento puede aparecer en cualquier parte de la linea de co- 
mando, ya que el codigo de activacion en main () busca en todos los argumentos. 
La comprobacion es bastante simple como se ve en la expresion: 

string(argv[i]) 


Esto toma la cadena argv [ i ] y crea un string, el cual se puede comparar facil- 
mente con lo que haya a la derecha de ==. El programa anterior busca la cadena com- 
pleta — debug=on. Tambien puede buscar — debug= y entonces ver que hay des¬ 
pues, para proporcionar mas opciones. El Volumen 2 (disponible en www.BruceEckel.com) 
contiene un capitulo dedicado a la clase string Estandar de C++. 

Aunque una bandera de depuracion es uno de los relativamente pocos casos en 
los que tiene mucho sentido usar una variable global, no hay nada que diga que debe 
ser asi. Fijese en que la variable esta escrita en minusculas para recordar al lector que 
no es una bandera del preprocesador. 
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3.9.2. Convertir variables y expresiones en cadenas 

Cuando se escribe codigo de depuracion, resulta pesado escribir expresiones 
print que consisten en una cadena que contiene el nombre de una variable, segui- 
do de el valor de la variable. Afortunadamente, el C estandar incluye el operador 
de FIXME cadenizacion #, que ya se uso antes en este mismo capitulo. Cuando se 
coloca un # antes de una argumentos en una macro, el preprocesador convierte ese 
argumentos en una cadena. Esto, combinado con el hecho de que las cadenas no in- 
dexadas colocadas una a continuacion de la otra se concatenan, permite crear macros 
muy adecuadas para imprimir los valores de las variables durante la depuracion: 

fdefine PR(x) cout << #x " = " << x << "\n"; 

Si se imprime la variable a invocando PR (a) , tendra el mismo efecto que este 
codigo: 

cout << "a = " << a << "\n"; 

Este mismo proceso funciona con expresiones completas. El siguiente programa 
usa una macro para crear un atajo que imprime la expresion cadenizadas y despues 
evalua la expresion e imprime el resultado: 

//: C03:StringizingExpressions.cpp 

#include <iostream> 

using namespace std; 

#define P(A) cout << #A << " << (A) << endl; 

int main() { 

int a = 1, b=2, c = 3; 

P (a) ; P(b); P (c) ; 

P (a + b) ; 

P ( (c - a) /b) ; 

} ///:~ 


Puede comprobar como una tecnica como esta se puede convertir rapidamente 
en algo indispensable, especialmente si no tiene depurador (o debe usar multiples 
entornos de desarrollo). Tambien puede insertar un #ifdef para conseguir que P- 
(A) se defina como «nada» cuando quiera eliminar el codigo de depuracion. 


3.9.3. La macro C assert() 

En el fichero de cabecera estandar <cassert> aparece assert (), que es una 
macro de depuracion. Cuando se utiliza assert (), se le debe dar un argumento 
que es una expresion que usted esta «aseverando». El preprocesador genera codigo 
que comprueba la asercion. Si la asercion no es cierta, el programa parara despues de 
imprimir un mensaje de error informando que la asercion fallo. Este es un ejemplo 
trivial: 

//: C03:Assert.cpp 

// Use of the assert () debugging macro 
#include <cassert> // Contains the macro 
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using namespace std; 

int main() { 

int i = 100; 

assert (i != 100); // Fails 
} ///:~ 


La macro original es C Estandar, asi que esta disponible tambien en el fichero de 
cabecera assert .h. 

Cuando haya terminado la depuration, puede eliminar el codigo generado por 
la macro escribiendo la siguiente linea: 

#define NDEBUG 

en el programa, antes de la inclusion de <cassert>, o definiendo NDEBUG en la 
linea de comandos del compilador. NDEBUG es una bandera que se usa en<cassert> 
para cambiar el codigo generado por las macros. 

Mas adelante en este libro, vera algunas alternativas mas sofisticadas aassert- 

(). 


3.10. Direcciones de funcion 

Una vez que una funcion es compilada y cargada en la computadora para ser 
ejecutada, ocupa un trozo de memoria. Esta memoria, y por tanto esa funcion, tiene 
una direction. 

C nunca ha sido un lenguaje [FIXME] donde otros temen pisar. Puede usar di¬ 
recciones de funcion con punteros igual que puede usar direcciones variables. La 
declaration y uso de punteros a funcion parece un poco opaca al principio, pero 
sigue el formato del resto del lenguaje. 


3.10.1. Definicion de un puntero a funcion 

Para definir un puntero a una funcion que no tiene argumentos y no retorna nada, 
se dice: 

void (*funcPtr)(); 

Cuando se observa una definicion compleja como esta, el mejor metodo para en- 
tenderla es empezar en el medio e ir hacia afuera. «Empezar en el medio» significa 
empezar con el nombre de la variable, que es f unPtr. «Ir hacia afuera» significa mi- 
rar al elemento inmediatamente a la derecha (nada en este caso; el parentesis derecho 
marca el fin de ese elemento), despues mire a la izquierda (un puntero denotado por 
el asterisco), despues mirar de nuevo a la derecha (una lista de argumentos vacia 
que indica que no funcion no toma argumentos), despues a la izquierda (void, que 
indica que la funcion no retorna nada). Este movimiento derecha-izquierda-derecha 
funciona con la mayoria de las declaraciones. 6 

6 (N. del T.) Otra forma similar de entenderlo es dibujar mentalmente una espiral que empieza en el 
medio (el identificador) y se va abriendo. 
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Para repasar, «empezar en el medio» («funcPtr es un ...», va a la derecha (nada 
aqui - pare en el parentesis derecho), va a la izquierda y encuentra el * («... puntero 
a ...»), va a la derecha y encuentra la lista de argumentos vada («... funcion que no 
tiene argumentos ...») va a la izquierda y encuentra el void («funcPtr es un puntero 
a una funcion que no tiene argumentos y retorna void»). 

Quiza se pregunte porque * f uncPtr necesita parentesis. Si no los usara, el com- 
pilador podria ver: 

void *funcPtr(); 


Lo que corresponde a la declaracion de una funcion (que retorna un void*) en 
lugar de definir una variable. Se podria pensar que el compilador seria capaz distin- 
guir una declaracion de una definicion por lo que se supone que es. El compilador 
necesita los parentesis para «tener contra que chocar» cuando vaya hacia la izquier¬ 
da y encuentre el *, en lugar de continuar hacia la derecha y encontrar la lista de 
argumentos vacia. 


3.10.2. Declaraciones y definiciones complicadas 

A1 margen, una vez que entienda como funciona la sintaxis de declaracion de C 
y C++ podra crear elementos mas complicados. Por ejemplo: 

//: V1C03:ComplicatedDefinitions.cpp 


/ * 

1. 

* / 

void * (*(*fpl) (int)) [10]; 

/ * 

2 . 

* / 

float (*(*fp2) (int,int,float)) (int); 

/ * 

3. 

* / 

typedef double (*(*(*fp3) ()) [10]) (); 




fp3 a; 

/ * 

4 . 

* / 

int (* (*f4()) [10]) (); 


int main() { } 


Estudie cada uno y use la regia derecha-izquierda para entenderlos. El numero 
1 dice «fpl es un puntero a una funcion que toma un entero como argumento y 
retorna un puntero a un array de 10 punteros void». 

El 2 dice «fp2 es un puntero a funcion que toma tres argumentos (int, int y float) 
de retorna un puntero a una funcion que toma un entero como argumento y retorna 
un float» 

Si necesita crear muchas definiciones complicadas, deberia usar typedef . El nu¬ 
mero 3 muestra como un typedef ahorra tener que escribir una description compli- 
cada cada vez. Dice «Un fp3 es un puntero a una funcion que no tiene argumentos 
y que retorna un puntero a un array de 10 punteros a funciones que no tienen ar¬ 
gumentos y retornan doubles». Despues dice «a es una variable de ese tipo fp3». 
typedef es util para construir descripciones complicadas a partir de otras simples. 

El 4 es una declaracion de funcion en lugar de una definicion de variable. Dice 
«f 4 es una funcion que retorna un puntero a un array de 10 punteros a funciones 
que retornan enteros». 
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Es poco habitual necesitar declaraciones y definiciones tan complicadas como 
estas. Sin embargo, si se propone entenderlas, no le desconcertaran otras algo menos 
complicadas pero que si encontrara en la vida real. 


3.10.3. Uso de un puntero a funcion 

Una vez que se ha definido un puntero a funcion, debe asignarle la direccion de 
una funcion antes de poder usarlo. Del mismo modo que la direccion de un array 
arr[10] se obtiene con el nombre del array sin corchetes (arr), la direccion de 
una funcion f unc () se obtiene con el nombre de la funcion sin lista de argumentos 
(func). Tambien puede usar una sintaxis mas explicita: Sfunc (). Para invocar la 
funcion, debe dereferenciar el puntero de la misma forma que lo ha declarado (re- 
cuerde que C y C++ siempre intentan hacer que las definiciones se parezcan al modo 
en que se usan). El siguiente ejemplo muestra como se define y usa un puntero a 
funcion: 

//: C03:PointerToFunction.cpp 

// Defining and using a pointer to a function 

#include <iostream> 

using namespace std; 

void func() { 

cout << "func() called..." << endl; 

1 


int main() { 

void (*fp) (); // Define a function pointer 

fp = func; // Initialize it 

(*fp)(); // Dereferencing calls the function 

void (*fp2) () = func; // Define and initialize 
( *fp2 ) () ; 

} ///:~ 


Una vez definido el puntero a funcion fp, se le asigna la direccion de una fun¬ 
cion func () usando fp = func (frjese que la lista de argumentos no aparece junto 
al nombre de la funcion). El segundo caso muestra una definicion e inicializacion 
simultanea. 


3.10.4. Arrays de punteros a funciones 

Una de las construcciones mas interesantes que puede crear es un array de punte¬ 
ros a funciones. Para elegir una funcion, solo indexe el array y dereferencie el punte¬ 
ro. Esto permite implementar el concepto de codigo dirigido por tabla(table-driven code ); 
en lugar de usar estructuras condicionales o sentencias case, se elige la funcion a eje- 
cutar en base a una variable (o una combinacion de variables). Este tipo de diseno 
puede ser util si anade y elimina funciones de la tabla con frecuencia (o si quiere 
crear o cambiar una tabla dinamicamente). 

El siguiente ejemplo crea algunas funciones falsas usando una macro de prepro- 
cesador, despues crea un array de punteros a esas funciones usando inicializacion 
automatica. Como puede ver, es facil anadir y eliminar funciones de la table (y por 
tanto, la funcionalidad del programa) cambiando una pequena porcion de codigo. 
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//: C03:FunctionTable.cpp 

// Using an array of pointers to functions 

#include <iostream> 

using namespace std; 

//A macro to define dummy functions: 

#define DF (N) void N() { \ 

cout << "function " #N " called..." << endl; } 

DF (a) ; DF (b); DF (c); DF (d) ; DF (e); DF( f); DF(g) ; 
void (*func_table[])() = { a, b, c, d, e, f, g }; 

int main () { 

whiled) { 

cout << "press a key from 'a' to 'g' " 

"or q to quit" << endl; 

char c, cr; 

cin.get(c); cin.get(cr); // second one for CR 
if ( c == 'q' ) 

break; // ... out of while(1) 

if ( c < ' a' | I c > ' g' ) 

continue; 

(*func_table[c - ' a'])(); 

} 

} ///:- 


A partir de este punto, deberia ser capaz de imaginar como esta tecnica podria 
resultarle util cuando tenga que crear algun tipo de interprete o programa para pro- 
cesar listas. 


3.11. Make: como hacer compilacion separada 

Cuando se usa compilacion separada (dividiendo el codigo en varias unidades de 
traduccion), aparece la necesidad de un medio para compilar automaticamente cada 
fichero y decirle al enlazador como montar todas las piezas - con las librerias apropia- 
das y el codigo de inicio - en un fichero ejecutable. La mayoria de los compiladores le 
permiten hacerlo desde una solo instruccion desde linea de comandos. Por ejemplo, 
para el compilador de C++ de GNU se puede hacer: 

| $ g++ SourceFilel.cpp SourceFile2.cpp 

En problema con este metodo es que el compilador compilara cada fichero indi¬ 
vidual tanto si el fichero necesita ser recompilado como sino. Cuando un proyecto 
tiene muchos ficheros, puede resultar prohibitivo recompilar todo cada vez que se 
cambia una linea en un fichero. 

La solucion a este problema, desarrollada en Unix pero disponible de alun mo- 
do en todos los sistemas es un programa llamado make. La utilidad make maneja 
todos los ficheros individuales de un proyecto siguiendo las instrucciones escritas 
en un fichero de texto llamado makefile. Cuando edite alguno de los ficheros del 
proyecto y ejecute make, el programa make seguira las directrices del makefile 
para comparar las fechas de los ficheros fuente con las de los ficheros resultantes 
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correspondientes, y si una fichero fuente es mas reciente que su fichero resultan- 
te, make recompila ese fichero fuente. make solo recompila los ficheros fuente que 
han cambiado, y cualquier otro fichero que este afectado por el fichero modificado. 
Usando make no tendra que recompilar todos los ficheros de su proyecto cada vez 
que haga un cambio, ni tendra que comprobar si todo se construye adecuadamen- 
te. El makefile contiene todas las instrucciones para montar el proyecto. Aprender 
a usar make le permitira ahorrar mucho tiempo y frustraciones. Tambien descubri- 
ra que make es el metodo tipico para instalar software nuevo en maquinas GNU o 
Unix 7 (aunque esos makefiles tienen a ser mucho mas complicados que los que 
aparecen en este libro, y a menudo podra generar automaticamente un makefile 
para su maquina particular como parte del proceso de instalacion). 

Como make esta disponible de algun modo para practicamente todos los compi- 
ladores de C++ (incluso si no lo esta, puede usar makes libres con cualquier compi- 
lador), sera la herramienta usada en este libro. Sin embargo, los fabricantes de com- 
piladores crean tambien sus propias herramientas para construir proyectos. Estas 
herramientas preguntan que ficheros hay en el proyecto y determinan las relaciones 
entre ellos. Estas herramientas utilizan algo similar a un makefile, normalmente 
llamado fichero de proyecto, pero el entorno de programacion mantiene este fichero 
para que el programador no tenga que preocuparse de el. La configuration y uso de 
los ficheros de proyecto varia de un entorno de desarrollo a otro, de modo que ten¬ 
dra que buscar la documentation apropiada en cada caso (aunque esas herramientas 
proporcionadas por el fabricante normalmente son tan simples de usar que es facil 
aprender a usarlas jugando un poco con ellas - mi metodo educativo favorito). 

Los makefiles que acompanan a este libro deberian funcionar bien incluso si 
tambien usa una herramienta especifica para construction de proyectos. 


3.11.1. Las actividades de Make 

Cuando escribe make (o cualquiera que sea el nombre del su programa make), 
make busca un fichero llamado makefile o Makefile en el directorio actual, que 
usted habra creado para su proyecto. Este fichero contiene una lista de dependencias 
entre ficheros fuente, make comprueba las fechas de los ficheros. Si un fichero tiene 
una fecha mas antigua que el fichero del que depende, make ejecuta la regia indicada 
despues de la dependencia. 

Todos los comentarios de los makefiles empiezan con un # y continuan hasta 
el fina de la linea. 

Como un ejemplo sencillo, el makefile para una programa llamado «hello» po- 
dria contener: 

# A comment 

hello.exe: hello.cpp 

mycompiler hello.cpp 


Esto dice que hello . exe (el objetivo) depende de hello . cpp. Cuando hello . 
cpp tiene una fecha mas reciente que hello . exe, make ejecuta la «regla» mycom- 
piler hello.cpp. Puede haber multiples dependencias y multiples reglas. Muchas im- 
plementaciones de make requieren que todas las reglas empiecen con un tabulador. 

7 (N. de T.) El metodo del que habla el autor se refiere normalmente a software instalado a partir de 
su codigo fuente. La instalacion de paquetes binarios es mucho mas simple y automatizada en la mayorfa 
de las variantes actuales del sistema operativo GNU. 
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Para lo demas, por norma general los espacios en bianco se ignoran de modo que se 
pueden usar a efectos de legibilidad. 

Las reglas no estan restringidas a llamadas al compilador; puede llamar a cual- 
quier programa que quiera. Creando grupos de reglas de dependencia, puede mo- 
dificar sus ficheros fuentes, escribir make y estar seguro de que todos los fichero 
afectados seran re-construidos correctamente. 

Macros 

Un makefile puede contener macros (tenga en cuenta que estas macros no tie- 
nen nada que ver con las del preprocesador de C/C++). La macros permiten reem- 
plazar cadenas de texto. Los makefiles del libro usan una macro para invocar el 
compilador de C++. Por ejemplo, 

CPP = mycompiler 
hello.exe: hello.cpp 

$ (CPP) hello.cpp 


El = se usa para indicar que CPP es una macro, y el $ y los parentesis expanden 
la macro. En este caso, la expansion significa que la llamada a la macro $ (CPP) 
sera reemplazada con la cadena mycompiler. Con esta macro, si quiere utilizar un 
compilador diferente llamado cpp, solo tiene que cambiar la macro a: 

CPP = cpp 

Tambien puede anadir a la macro opciones del compilador, etc., o usar otras ma¬ 
cros para anadir dichas opciones. 

Reglas de sufijo 

Es algo tedioso tener que decir a make que invoque al compilador para cada 
fichero cpp del proyecto, cuando se sabe que basicamente siempre es el mismo pro- 
ceso. Como make esta disenado para ahorrar tiempo, tambien tiene un modo de 
abreviar acciones, siempre que dependan del sufijo de los ficheros. Estas abreviatu- 
ras se llaman reglas de sufijo. Una regia de sufijo es la la forma de indicar a make 
como convertir un fichero con cierta extension (. cpp por ejemplo) en un fichero con 
otra extension (. ob j o . exe). Una vez que le haya indicado a make las reglas para 
producir un tipo de fichero a partir de otro, lo unico que tiene que hacer es decirle a 
make cuales son las dependencias respecto a otros ficheros. Cuando make encuen- 
tra un fichero con una fecha previa a otro fichero del que depende, usa la regia para 
crear la version actualizada del fichero objetivo. 

La regia de sufijo le dice a make que no se necesitan reglas explicitas para cons- 
truir cada cosa, en su lugar le explica como construir cosas en base a la extension del 
fichero. En este caso dice «Para contruir un fichero con extension . exe a partir de 
uno con extension . cpp, invocar el siguiente comando». Asi seria para ese ejemplo: 

CPP = mycompiler 
.SUFFIXES: .exe .cpp 
.cpp.exe: 

$(CPP) $< 


La directiva . SUFFIXES le dice a make que debe vigilar las extensiones que se 
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indican porque tiene un significado especial para este makefile en particular. Lo 
siguiente que aparece es la regia de sufijo . cpp . exe, que dice «como convertir cual- 
quier fichero con extension . cpp a uno con extension . exe» (cuando el fichero . cpp 
es mas reciente que el fichero .. exe). Como antes, se usa la macro $ (CPP) , pero aqui 
aparece algo nuevo: $<. Como empieza con un $ es que es una macro, pero esta es 
una de las macros especiales predefinidas por make. El $< se puede usar solo en 
reglas de sufijo y significa «cualquier prerrequisito que dispare la regla» (a veces 
llamado dependencia), que en este caso se refiere al «fichero . cpp que necesita ser 
compilado». 

Una ver que las reglas de sufijo se han fijado, puede indicar por ejemplo algo 
tan simple como make Union.exe y se aplicara la regia sufijo, incluso aunque no se 
mencione «Union» en ninguna parte del makefile. 

Objetivos predeterminados 

Despues de las macros y las reglas de sufijo, make busca la primero «regla» del 
fichero, y la ejecuta, a menos que se especifica una regia diferente. Asi que pare el 
siguiente makefile: 

CPP = mycompiler 
.SUFFIXES: .exe .cpp 
.cpp.exe: 

$(CPP) $< 
targetl.exe: 
target2.exe: 


Si ejecuta simplemente make, se construira target 1. exe (usando la regia de su¬ 
fijo predeterminada) porque ese es el primer objetivo que make va a encontrar. Para 
construir target2 . exe se debe indicar explicitamente diciendo make target2.exe. 
Esto puede resultar tedioso de modo que normalmente se crea un objetivo «dummy» 
por defecto que depende del resto de objetivos, como este: 

CPP = mycompiler 
.SUFFIXES: .exe .cpp 
.cpp.exe: 

$(CPP) $< 

all: targetl.exe target2.exe 


Aqui, all no existe y no hay ningun fichero llamada all, asi que cada vez que 
ejecute make, el programa vera que a 11 es el primer objetivo de la lista (y por tanto el 
objetivo por defecto), entonces comprobara que all no existe y analizara sus depen¬ 
dences. Comprueba target 1. exe y (usando la regia de sufijo) comprobara (1) que 
targetl. exe existey (2) que targetl. cpp es mas reciente que targetl. exe ,y 
si es asi ejecutara la regia (si proporciona una regia explicita para un objetivo concre- 
to, se usara esa regia en su lugar). Despues pasa a analizar el siguiente fichero de la 
lista de objetivos por defecto. De este modo, breando una lista de objetivos por defec¬ 
to (tipicamente llamada all por convenio, aunque se puede tener cualquier nombre) 
puede conseguir que se construyan todos los ejecutables de su proyecto simplemen¬ 
te escribiendo make. Ademas, puede tener otras listas de objetivos para hacer otras 
cosas - por ejemplo, podria hacer que escribiendo make debug se reconstruyeran 
todos los ficheros pero incluyendo informacion de depuracion. 
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3.11.2. Los Makefiles de este libro 

Usando el programa ExtractCode. cpp del Volumen 2 de este libro, se han 
extraido automaticamente todos los listado de codigo de este libro a partir de la 
version en texto ASCII y se han colocado en subdirectories de acuerdo a sus capl- 
tulos. Ademas, ExtractCode . cpp crea varios makefiles en cada subdirectorio 
(con nombres diferentes) para que pueda ir a cualquier subdirectorio y escribir ma¬ 
ke -f mycompiler.makefile (sustituyendo «mycompiler» por el nombre de su com- 
pilador, la opcion -f dice «utiliza lo siguiente como un makefile®). Finalmente, 
ExtractCode . cpp crea un makefile «maestro» en el directorio ralz donde se ha- 
yan extraido los fichero del libro, y este makefile descienda a cada subdirectorio y 
llama a make con el makefile apropiado. De este modo, se puede compilar todo 
el codigo de los listados del libro invocando un unico comando make, y el proceso 
parara cada vez que su compilador no pueda manejar un fichero particular (tenga 
presente que un compilador conforme al Estandar C++ deberla ser compatible con 
todos los ficheros de este libro). Como algunas implementaciones de make varlan de 
un sistema a otro, en los makefiles generados se usan solo las caracterlsticas mas 
basicas y comunes. 


3.11.3. Un ejemplo de Makefile 

Tal como se mencionaba, la herramienta de extraction de codigo ExtractCode. 
cpp genera automaticamente makefiles para cada capitulo. Por eso, los makefiles 
de cada capitulo no aparecen en el libro (todos los makefiles estan empaquetados 
con el codigo fuente, que se puede descargar de www.BruceEckel.com). Sin embar¬ 
go, es util ver un ejemplo de un makefile. Lo siguiente es una version recortada 
de uno de esos makefiles generados automaticamente para este capitulo. Encon- 
trara mas de un makefile en cada subdirectorio (tienen nombres diferentes; puede 
invocar uno concreto con make -f. Este es para GNU C++: 

CPP = g++ 

OFLAG = -o 

.SUFFIXES : .o .cpp . c 

.cpp.o : 

$(CPP) $(CPPFLAGS) -c $< 

. c. o : 

$(CPP) $(CPPFLAGS) -c $< 

all: \ 

Return \ 

Declare \ 

Ifthen \ 

Guess \ 

Guess2 

# Rest of the files for this chapter not shown 

Return: Return.o 

$(CPP) $(OFLAG)Return Return.o 

Declare: Declare.o 

$(CPP) $ (OFLAG)Declare Declare.o 

Ifthen: Ifthen.o 

$(CPP) $(OFLAG)Ifthen Ifthen.o 
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Guess: Guess, o 

$(CPP) $(OFLAG)Guess Guess, o 

Guess2: Guess2.o 

$(CPP) $(OFLAG)Guess2 Guess2.o 

Return.o: Return.cpp 
Declare.o: Declare.cpp 
Ifthen.o: Ifthen.cpp 
Guess.o: Guess.cpp 
Guess2.o: Guess2.cpp 


La macro CPP contiene el nombre del compilador. Para usar un compilador di- 
ferente, puede editar el makefile o cambiar el valor de la macro desde linea de 
comandos, algo como: 


$ make CPP=cpp 


Tenga en cuenta, sin embargo, que ExtractCode . cpp tiene un esquema auto- 
matico para construir makefiles para compiladores adicionales. 

La segunda macro OFLAG es la opcion que se usa para indicar el nombre del 
fichero de salida. Aunque muchos compiladores asumen automaticamente que el 
fichero de salida tiene el mismo nombre base que el fichero de entrada, otros no 
(como los compiladores GNU/Unix, que por defecto crean un fichero llamado a. 

out). 

Como ve, hay dos reglas de sufijo, una para ficheros . cpp y otra para fichero . c 
(en caso de que se necesite compilar algun fuente C). El objetivo por defecto es all, 
y cada linea de este objetivo esta «continuada» usando la contrabarra, hasta Guess2, 
que el el ultimo de la lista y por eso no tiene contrabarra. Hay muchos mas fichero 
en este capitulo, pero (por brevedad) solo se muestran algunos. 

Las reglas de sufijo se ocupan de crear fichero objeto (con extension . o) a partir 
de los fichero . cpp, pero en general se necesita escribir reglas explicitamente para 
crear el ejecutable, porque normalmente el ejecutable se crea enlazando muchos fi¬ 
chero objeto diferente y make no puede adivinar cuales son. Tambien, en este caso 
(GNU/Unix) no se usan extensiones estandar para los ejecutables de modo que una 
regia de sufijo no sirve para esas situaciones. Por eso, vera que todas las reglas para 
construir el ejecutable final se indican explicitamente. 

Este makefile toma el camino mas seguro usando el minimo de prestaciones 
de make; solo usa los conceptos basicos de objetivos y dependencias, y tambien ma¬ 
cros. De este modo esta practicamente asegurado que funcionara con la mayoria 
de las implementaciones de make. Eso implica que se producen fichero makefile 
mas grandes, pero no es algo negativo ya que se generan automaticamente por 
ExtractCode.cpp. 

Hay muchisimas otras prestaciones de make que no se usan en este libro, inclu- 
yendo las versiones mas nuevas e inteligentes y las variaciones de make con atajos 
avanzados que permiten ahorrar mucho tiempo. La documentacion propia de cada 
make particular describe en mas profundidad sus caracteristicas; puede aprender 
mas sobre make en Managing Projects with Make de Oram y Taiboot (O'Reilly, 1993). 
Tambien, si el fabricante de su compilador no proporciona un make o usa uno que no 
es estandar, puede encontrar GNU Make para practicamente todas las plataformas 
que existen buscado en los archivos de GNU en internet (hay muchos). 




'Volumenl" — 2012/1/12 — 13:52 — page 136 — #174 


Capitulo 3. C en C++ 


3.12. Resumen 

Este capitulo ha sido un repaso bastante intenso a traves de todas las caracteris- 
ticas fundamentales de la sintaxis de C++, la mayoria heredada de C (y ello redunda 
la compatibilidad hacia atras FIXME:vaunted de C++ con C). Aunque algunas carac- 
teristicas de C++ se han presentado aqui, este repaso esta pensado principalmente 
para personas con experiencia en programacion, y simplemente necesitan una in- 
troduccion a la sintaxis basica de C y C++. Incluso si usted ya es un programador 
de C, puede que haya visto una o dos cosas de C que no conoda, aparte de todo lo 
referente a C++ que probablemente sean nuevas. Sin embargo, si este capitulo le ha 
sobrepasado un poco, deberia leer el curso en CD ROM Thinking in C: Foundations for 
C++ and Java que contiene lecturas, ejercicios, y soluciones guiadas), que viene con 
este libro, y tambien esta disponible en www.BruceEckel.com. 

3.13. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Cree un fichero de cabecera (con extension «.h»). En este fichero, declare un 
grupo de funciones variando las listas de argumentos y valores de retorno de 
entre los siguientes: void, char, int y float. Ahora cree un fichero . cpp que 
incluya su fichero de cabecera y haga definiciones para todas esas funciones. 
Cada definicion simplemente debe imprimir en nombre de la funcion, la lista 
de argumentos y el tipo de retorno para que se sepa que ha sido llamada. Cree 
un segundo fichero . cpp que incluya el fichero de cabecera y defina una int 
main ( ), que contenga llamadas a todas sus funciones. Compile y ejecute su 
programa. 

2. Escriba un programa que use dos bucles for anidados y el operador modulo 
(%) para detectar e imprimir numeros enteros (numeros enteros solo divisibles 
entre si mismos y entre 1). 

3 . Escriba un programa que utilice un bucle wh i 1 e para leer palabras de la entra- 
da estandar (cin) y las guarde en un string. Este es un bucle while «infinito», 
que debe romper (y salir del programa) usando la sentencia break. Por cada 
palabra que lea, evaluela primero usando una secuencia de sentencias i f para 
«mapear» un valor entero de la palabra, y despues use una sentencia switch 
que utilice ese valor entero como selector (esta secuencia de eventos no es un 
buen estilo de programacion; solamente es un supuesto para que practique con 
el control de flujo). Dentro de cada case, imprima algo con sentido. Debe deci- 
dir cuales son las palabras interesantes y que significan. Tambien debe decidir 
que palabra significa el fin del programa. Pruebe el programa redireccionan- 
do un fichero como entrada (si quiere ahorrarse tener que escribir, ese fichero 
puede ser el propio codigo fuente del programa). 

4. Modifique Menu . cpp para usar sentencias switch en lugar de if. 

5. Escriba un programa que evalue las dos expresiones de la seccion llamada 
«precedencia». 

6. Modifique YourPets2 . cpp para que use varios tipos de datos distintos (char, 
int, float, double, y sus variantes). Ejecute el programa y cree un mapa del es- 
quema de memoria resultante. Si tiene acceso a mas de un tipo de maquina. 
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sistema operative), o compilador, intente este experimento con tantas variacio- 
nes como pueda manejar. 

7. Cree dos funciones, una que tome un string* y una que tome un string&. Cada 
una de estas funciones deberia modificar el objeto externo a su manera. En m- 
ain (), cree e inicialice un objeto string, imprimalo, despues paselo a cada una 
de las dos funciones, imprimiendo los resultados. 

8. Escriba un programa que use todos los trigrafos para ver si su compilador los 
soporta. 

9. Compile y ejecute Static . cpp. Elimine la palabra reservada static del co- 
digo, compile y ejecutelo de nuevo, y explique lo que ocurre. 

10. Intente compilar y enlazar FileStatic . cpp con FileStatic2 . cpp. ^Que 
significan los mensajes de error que aparecen? 

11. Modifique Boolean, cpp para que funcione con valores double en lugar de 
inf. 

12. Modifique Boolean . cpp y Bitwise . cpp de modo que usen los operadores 
explicitos (si su compilador es conforme al Estandar C++ los soportara). 

13. Modifique Bitwise . cpp para usar las funciones de Rotation . cpp. Asegu- 
rese de que muestra los resultados que deje claro que ocurre durante las rota- 
ciones. 

14. Modifique Ifthen . cpp para usar el operador if-else ternario(? :). 

15. Cree una struct que contenga dos objetos string y uno inf. Use un type- 
def para el nombre de la struct. Cree una instancia de la struct, inicialice 
los tres valores de la instancia, y muestrelos en pantalla. Tome la direccion de 
su instancia y asignela a un puntero a tipo de la struct. Usando el puntero, 
Cambie los tres valores de la instancia y muestrelos. 

16. Cree un programa que use un enumerado de colores. Cree una variable de este 
tipo enum y, utilizando un bucle, muestre todos los numeros que corresponden 
a los nombres de los colores. 

17. Experimente con Union. cpp eliminando varios elementos de la union para 
ver el efecto que causa en el tamano de la union resultante. Intente asignar 
un elemento (por tanto un tipo) de la union y muestrelo por medio de un 
elemento diferente (por tanto, un tipo diferente) para ver que ocurre. 

18. Cree un programa que defina dos arrays de int, uno a continuacion del otro. 
Indexe el primer array mas alia de su tamano para caer sobre el segundo, haga 
una asignacion. Muestre el segundo array para ver los cambios que eso ha 
causado. Ahora intente definir una variable char entre las definiciones de los 
arrays, y repita el experimento. Quiza quiera crear una funcion para imprimir 
arrays y asi simplificar el codigo. 

19. Modifique ArrayAddresses . cpp para que funcione con los tipos de datos 
char, long int, float y double. 

20. Aplique la tecnica de ArrayAddresses. cpp para mostrar el tamano de la 
struct y las direcciones de los elementos del array de StructArray. cpp. 

21. Cree un array de objetos string y asigne una cadena a cada elemento. Muestre 
el array usando un bucle for. 
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22. Cree dos nuevos programas a partir de ArgsToInts . cpp que usen atol () 
y at of () respectivamente. 

23. Modifique PointerIncrement2 . cpp de modo que use una union en lugar 
de una struct. 

24. Modifique Pointer Arithmetic . cpp para que funcione con long y long dou¬ 
ble. 

25. Defina una variable float. Tome su direccion, moldee esa direccion a un un¬ 
signed char, y asignela a un puntero unsigned char. Usando este puntero y 
[ ], indexe la variable float y use la funcion printBinary () definida en este 
capitulo para mostrar un mapa de cada float (vaya desde 0 hasta sizeof (f- 
loat) ). Cambie el valor del float y compruebe si puede averiguar que hay en 
el float (el float contiene datos codificados). 

26. Defina un array de int. Tome la direccion de comienzo de ese array y utilice 
static_cast para convertirlo a un void*. Escriba una funcion que tome un 
void*, un numero (que indica el numero de bytes), y un valor (indicando el va¬ 
lor que deberia ser asignado a cada byte) como argumentos. La funcion debe- 
ria asignar a cada byte en el rango especificado el valor dado como argumento. 
Pruebe la funcion con su array de int. 

27. Cree un array const de double y un array volatile de double. Indexe cada 
array y utilice const_cast para moldear cada elemento de no-const y no¬ 
volatile, respectivamente, y asigne un valor a cada elemento. 

28. Cree una funcion que tome un puntero a un array de double y un valor indi¬ 
cando el tamano de ese array. La funcion deberia mostrar cada valor del array. 
Ahora cree un array de double y inicialice cada elemento a cero, despues uti¬ 
lice su funcion para mostrar el array. Despues use reinterpret_cast para 
moldear la direccion de comienzo de su array a un unsigned char*, y ponga a 1 
cada byte del array (aviso: necesitara usar sizeof para calcular el numero de 
bytes que tiene un double). Ahora use su funcion de impresion de arrays para 
mostrar los resultados. <T’or que cree los elementos no tienen el valor 1.0? 

29. (Reto) Modifique FloatingAsBinary. cpp para que muestra cada parte del 
double como un grupo separado de bits. Tendra que reemplazar las llamadas 
a printBinary () con su propio codigo especifico (que puede derivar de p- 
rintBinary ()) para hacerlo, y tambien tendra que buscar y comprender el 
formato de punto flotante incluyendo el ordenamiento de bytes para su com- 
pilador (esta parte es el reto). 

30. Cree un makefile que no solo compile YourPetsl. cpp y YourPets2 . cpp 

(para cada compilador particular) sino que tambien ejecute ambos programas 
como parte del comportamiento del objetivo predeterminado. Asegurese de 
usar las reglas de sufijo. 

31. Modifique StringizingExpressions . cpp para que P (A) sea condicional- 
mente definida con #ifdef para permitir que el codigo de depuration sea 
eliminado automaticamente por medio de una bandera en linea de comandos. 
Necesitara consultar la documentation de su compilador para ver como definir 
y eliminar valores del preprocesador en el compilador de linea de comandos. 

32. Defina una funcion que tome un argumento double y retorne un int. Cree e ini¬ 
cialice un puntero a esta funcion, e invoque la funcion por medio del puntero. 
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33. Declare un puntero a un funcion que toma un argumento int y retorna un pun- 
tero a una funcion que toma un argumento char y retorna un float. 

34. Modifique Funct ionTable . cpp para que cada funcion retorne un string (en 
lugar de mostrar un mensaje) de modo que este valor se imprima en main (). 

35. Cree un makefile para uno de los ejercicios previos (a su election) que le per- 
mita escribir make para construir una version en production del programa y 
make debug para construir una version del programa que incluye information 
de depuration. 
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4: Abstraction de Datos 

C++ es una herramienta de mejora de la productividad. ^Por que 
si no harfa el esfuerzo (y es un esfuerzo, a pesar de lo facil que inte- 
temos hacer la transicion) 


de cambiar de algun lenguaje que ya conoce y con el cual ya es productivo a 
un nuevo lenguaje con el que sera menos productivo durante un tiempo, hasta que 
se haga con el? Se debe a que esta convencido de que conseguira grandes ventajas 
usando esta nueva herramienta. 

En terminos de programacion, productividad significa que menos personas, en 
menos tiempo, puedan realizar programas mas complejos y significativos. Desde 
luego, hay otras cuestiones que nos deben importar a la hora de escoger un lenguaje 
de programacion. Aspectos a tener en cuenta son la eficiencia (yla naturaleza del len¬ 
guaje hace que nuestros programas sean lentos o demasiado grandes?), la seguridad 
(ynos ayuda el lenguaje a asegurarnos de que nuestros programas hagan siempre lo 
que queremos? <puaneja el lenguaje los errores apropiadamente?) y el mantenimien- 
to (^el lenguaje ayuda a crear codigo facil de entender, modificar y extender?). Estos 
son, con certeza, factores importantes que se examinaran en este libro. 

Pero la productividad real significa que un programa que para ser escrito, antes 
requerla de tres personas trabajando una semana, ahora le lleve solo un dla o dos 
a una sola persona. Esto afecta a varios niveles de la esfera economica. A usted le 
agrada ver que es capaz de construir algo en menos tiempo, sus clientes (o jefe) 
estan contentos porque los productos les llegan mas rapido y utilizando menos mano 
de obra y finalmente los compradores se alegran porque pueden obtener productos 
mas baratos. La unica manera de obtener incrementos masivos en productividad es 
apoyandose en el codigo de otras personas; o sea, usando librerlas. 

Una librerla es simplemente un monton de codigo que alguien ha escrito y em- 
paquetado todo junto. Muchas veces, el paquete mmimo es tan solo un archivo con 
una extension especial como lib y uno o mas archivos de cabecera que le dicen al 
compilador que contiene la librerla. El enlazador sabra como buscar el archivo de la 
librerla y extraer el codigo compilado correcto. Sin embargo, esta es solo una forma 
de entregar una librerla. En plataformas que abarcan muchas arquitecturas, como 
GNU o Unix, el unico modo sensato de entregar una librarla es con codigo fuente 
para que as! pueda ser reconfigurado y reconstruido en el nuevo objetivo. 

De esta forma, las librerlas probablemente sean la forma mas importante de pro- 
gresar en terminos de productividad y uno de los principales objetivos del diseno de 
C++ es hacer mas facil el uso de librerlas. Esto implica entonces, que hay algo diflcil 
al usar librerlas en C. Entender este factor le dara una primera idea sobre el diseno 
de C++, y por lo tanto, de como usarlo. 
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4.1. Una libreria pequena al estilo C 

Aunque muchas veces, una libreria comienza como una coleccion de funciones, 
si ha usado alguna libreria C de terceros habra observado que la cosa no termina ahi 
porque hay mas que comportamiento, acciones y funciones. Tambien hay caracterls- 
ticas (azul, libras, textura, luminiscencia), las cuales estan representadas por datos. 
En C, cuando debemos representar caracteristicas, es muy conveniente agruparlas 
todas juntas en una estructura, especialmente cuando queremos representar mas de 
un tipo de cosa en el problema. Asi, se puede trabajar con una variable de esta es- 
tructuras para representar cada cosa. 

Por eso, la mayoria de las librerias en C estan formadas por un conjunto de es- 
tructuras y funciones que actuan sobre las primeras. Como ejemplo de esta tecnica, 
considere una herramienta de programacion que se comporta como un array, pero 
cuyo tamano se puede fijar en tiempo de ejecucion, en el momento de su creation. 
La llamaremos CStash 1 . Aunque esta escrito en C++, tiene el estilo clasico de una 
libreria escrita en C: 

//: C04:CLib.h 

// Header file for a C-like library 

// An array-like entity created at runtime 

typedef struct CStashTag { 

int size; // Size of each space 

int quantity; // Number of storage spaces 
int next; // Next empty space 

// Dynamically allocated array of bytes: 

unsigned char* storage; 

} CStash; 

void initialize(CStash* s, int size); 
void cleanup(CStash* s); 

int add(CStash* s, const void* element); 
void* fetch(CStash* s, int index); 
int count (CStash* s); 

void inflate (CStash* s, int increase); 

III : ~ 


Normalmente se utiliza un «rotulo» como CStashTag en aquellas estructuras que 
necesitan referenciarse dentro de si mismas. Ese es el caso de una lista enlazada (cada 
elemento de la lista contiene un puntero al siguiente elemento) se necesita un pun- 
tero a la siguiente variable estructura, o sea, una manera de identificar el tipo de ese 
puntero dentro del cuerpo de la propia estructura. En la declaration de las estructu¬ 
ras de una libreria escrita en C tambien es muy comun ver el uso de typedef como 
el del ejemplo anterior. Esto permite al programador tratar las estructuras como un 
nuevo tipo de dato y as! definir nuevas variables (de esa estructura) del siguiente 
modo: 

CStash A, B, C; 


El puntero storage es un unsigned chart Un unsigned char es la menor pieza 


1 N de T:«Stash» se podria traducir como «Acumulador». 
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de datos que permite un compilador C, aunque en algunas maquinas puede ser de 
igual tamano que la mayor. Aunque es dependiente de la implementacion, por lo ge¬ 
neral un unsigned char tiene un tamano de un byte. Dado que CStash esta disenado 
para almacenar cualquier tipo de estructura, el lector se puede preguntar si no seria 
mas apropiado un puntero void *. Sin embargo, el objetivo no es tratar este punte- 
ro de almacenamiento como un bloque de datos de tipo desconocido, sino como un 
bloque de bytes contiguos. 

El archivo de codigo fuente para la implementacion (del que no se suele disponer 
si fuese una libreria comercial —normalmente solo dispondra de un . ob j, . lib o 
. dll, etc) tiene este aspecto: 

//: C04:CLib.cpp {0} 

// Implementation of example C-like library 
// Declare structure and functions: 

#include "CLib.h" 

#include <iostream> 

#include <cassert> 
using namespace std; 

// Quantity of elements to add 
// when increasing storage: 
const int increment = 100; 

void initialize(CStash* s, int sz) { 
s->size = sz; 
s->quantity = 0; 
s->storage = 0; 
s->next = 0; 

} 


int add(CStash* s, const void* element) { 

if(s->next >= s->quantity) //Enough space left? 

inflate(s, increment); 

// Copy element into storage, 

// starting at next empty space: 
int startBytes = s->next * s->size; 
unsigned char* e = (unsigned char* )element; 
for(int i = 0; i < s->size; i++) 

s->storage[startBytes + i] = e[i]; 
s->next++; 

return (s->next - 1); // Index number 


void* fetch (CStash* s, int index) { 

// Check index boundaries: 
assert (0 <= index); 
if (index >= s->next) 

return 0; //To indicate the end 
// Produce pointer to desired element: 
return &(s->storage[index * s->size]); 


int count(CStash* s) { 

return s->next; // Elements in CStash 

} 


void inflate(CStash* s, int increase) { 
assert (increase > 0) ; 
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int newQuantity = s->quantity + increase; 
int newBytes = newQuantity * s->size; 
int oldBytes = s->quantity * s->size; 
unsigned char* b = new unsigned char [newBytes]; 
for (int i = 0; i < oldBytes; i++) 

b[i] = s->storage[i]; // Copy old to new 
delete [] (s->storage); // Old storage 
s->storage = b; // Point to new memory 
s->quantity = newQuantity; 

} 

void cleanup(CStash* s) { 
if (s->storage != 0) { 

cout << "freeing storage" << endl; 
delete [ ]s->storage; 

} 

} ///:~ 


initialize () realiza las operaciones iniciales necesarias para la struct CStash, 
poniendo los valores apropiados en las variables internas. Inicialmente, el puntero 
storage tiene un cero dado que aun no se ha almacenado nada. 

La funcion add () inserta un elemento en el siguiente lugar disponible de la CS¬ 
tash. Para lograrlo, primero verifica que haya suficiente espacio disponible. Si no lo 
hay, expande el espacio de almacenamiento (storage) usando la funcion inf lat- 
e () que se describe despues. 

Como el compilador no conoce el tipo especifico de la variable que esta siendo 
almacenada (todo lo que obtiene la funcion es un void*), no se puede hacer una 
asignacion simple, que seria lo mas conveniente. En lugar de eso, la variable se copia 
byte a byte. La manera mas directa de hacerlo es utilizando el indexado de arrays. Lo 
habitual es que en storage ya haya bytes almacenados, lo cual es indicado por el 
valor de next. Para obtener la posicion de insercion correcta en el array, se multiplica 
next por el tamano de cada elemento (en bytes) lo cual produce el valor de start- 
Bytes. Luego el argumento element se moldea a unsigned char* para que se pueda 
direccionar y copiar byte a byte en el espacio disponible de storage. Se incrementa 
next de modo que indique el siguiente lugar de almacenamiento disponible y el 
«indice» en el que ha almacenado el elemento para que el valor se puede recuperar 
utilizando el indice con f etch (). 

fetch () verifica que el indice tenga un valor correcto y devuelve la direccion 
de la variable deseada, que se calcula en funcion del argumento index. Dado que 
index es un desplazamiento desde el principio en la CStash, se debe multiplicar 
por el tamano en bytes que ocupa cada elemento para obtener dicho desplazamiento 
en bytes. Cuando utilizamos este desplazamiento como indice del array storage lo 
que obtenemos no es la direccion, sino el byte almacenado. Lo que hacemos entonces 
es utilizar el operador direccion-de &. 

count () puede parecer un poco extraha a los programadores experimentados 
en C. Podria parecer demasiado complicada para una tarea que probablemente sea 
mucho mas facil de hacer a mano. Por ejemplo, si tenemos una CStash llamada i- 
ntStash, es mucho mas directo preguntar por la cantidad de elementos utilizando 
intStash . next, que llamar a una funcion (que implica sobrecarga), como coun- 
t (SintStash) . Sin embargo, la cantidad de elementos se calcula en funcion tanto 
del puntero next como del tamano en bytes de cada elemento de la CStash; por 
eso la interfaz de la funcion count () permite la flexibilidad necesaria para no tener 
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que preocuparnos por estas cosas. Pero, jay!, la mayoria de los programadores no se 
preocuparan por descubrir lo que para nosotros es el «mejor» diserio para la libreria. 
Probablemente lo que haran es mirar dentro de la estructura y obtener el valor de 
next directamente. Peor aun, podrian incluso cambiar el valor de next sin nuestro 
permiso. jSi hubiera alguna forma que permitiera al disenador de la libreria tener un 
mejor control sobre este tipo de cosas! (Si, esto es un presagio). 


4.1.1. Asignacion dinamica de memoria 

Nunca se puede saber la cantidad maxima de almacenamiento que se necesitara 
para una CStash, por eso la memoria a la que apuntan los elementos de storage se 
asigna desde el monticulo (heap) 2 . El monticulo es un gran bloque de memoria que 
se utiliza para asignar en pequenos trozos en tiempo de ejecucion. Se usa el heap 
cuando no se conoce de antemano la cantidad de memoria que necesitara el progra- 
ma que esta escribiendo. Por ejemplo, eso ocurre en un programa en el que solo en 
el momento de la ejecucion se sabe si se necesia memoria para 200 variables Avion 
o para 20. En C Estandar, las funciones para asignacion dinamica de memoria inclu- 
yen malloc (), calloc () , realloc ( ) y free ( ). En lugar de llamadas a librerias, 
C++ cuenta con una tecnica mas sofisticada (y por lo tanto mas facil de usar) para 
tratar la memoria dinamica. Esta tecnica esta integrada en el lenguaje por medio de 
las palabras reservadas new y delete. 

La funcion inflate () usa new para obtener mas memoria para la CStash. En 
este caso el espacio de memoria solo se amplia y nunca se reduce, assert () garan- 
tiza que no se pase un numero negativo como argumento a inflate () como valor 
de incremento. La nueva cantidad de elmentos que se podran almacenar (una vez 
se haya terminado inflate () ) se determina en la variable newQuantity que se 
multiplica por el numero de bytes que ocupa cada elemento, para obtener el nuevo 
numero total de bytes de la asignacion en la variable newBytes. Dado que se sa¬ 
be cuantos bytes hay que copiar desde la ubicacion anterior, oldBytes se calcula 
usando la cantidad antigua de bytes (quantity). 

La peticion de memoria ocurre realmente en la expresion-new que involucra la 
palabra reservada new: 

new unsigned char[newBytes]; 

La forma general de una expresion-new es: 

new Tipo; 


donde Tipo describe el tipo de variable para la cual se solicita memoria en el mon¬ 
ticulo. Dado que en este caso, se desea asignar memoria para un array de unsigned 
char de newBytes elementos, eso es lo que aparece como Tipo. Del mismo modo, se 
puede asignar memoria para algo mas simple como un int con la expresion: 

new int; 


y aunque esto se utiliza muy poco, demuestra que la sintaxis es consistente. 

Una expresion-new devuelve un puntero a un objeto del tipo exacto que se le pidio. 

2 N. de T.: heap se suele tradudr al Castellano como «monton» o «monticulo». 
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De modo que con new Tipo se obtendra un puntero a un objeto de tipo Tipo, y con 
new int obtendra un puntero a un int. Si quiere un nuevo array de unsigned char 
la expresion devolvera un puntero al primer elemento de dicho array. El compilador 
verificara que se asigne lo que devuelve la expresion-new a una variable puntero del 
tipo adecuado. 

Por supuesto, es posible que al pedir memoria, la peticion falle, por ejemplo, si 
no hay mas memoria libre en el sistema. Como vera mas adelante, C++ cuenta con 
mecanismos que entran en juego cuando la operacion de asignacion de memoria no 
se puede satisfacer. 

Una vez que se ha obtenido un nuevo espacio de almacenamiento, los datos que 
estaban en el antiguo se deben copiar al nuevo. Esto se hace, nuevamente, en un 
bucle, utilizando la notacion de indexado de arrays, copiando un byte en cada itera¬ 
tion del bucle. Una vez finalizada esta copia, ya no se necesitan los datos que estan 
en el espacio de almacenamiento original por lo que se pueden liberar de la memoria 
para que otras partes del programa puedan usarlo cuando lo necesiten. La palabra 
reservada delete es el complemento de new y se debe utilizar sobre todas aquellas 
variables a las cuales se les haya asignado memoria con new. (Si se olvida de utilizar 
delete esa memoria queda in-utilizable. Si estas fugas de memoria (memory leak) 
son demasiado abundantes, la memoria disponible se acabara.) Existe una sintaxis 
especial cuando se libera un array. Es como si recordara al compilador que ese pun¬ 
tero no apunta solo a un objeto, sino a un array de objetos; se deben poner un par de 
corchetes delante del puntero que se quiere liberar: 

delete []myArray; 


Una vez liberado el antiguo espacio de almacenamiento, se puede asignar el pun¬ 
tero del nuevo espacio de memoria al puntero storage, se actualiza quantity y 
con eso inflate () ha terminado su trabajo. 

En este punto es bueno notar que el administrador de memoria del monticulo> 
es bastante primitivo. Nos facilita trozos de memoria cuando se lo pedimos con new 
y los libera cuando invocamos a delete. Si un programa asigna y libera memoria 
muchas veces, terminaremos con un monticulo fmgmentado, es decir un monticulo 
en el que si bien puede haber memoria libre utilizable, los trozos de memoria estan 
divididos de tal modo que no exista un trozo que sea lo suficientemente grande pa¬ 
ra las necesidades concretas en un momento dado. Lamentablemente no existe una 
capacidad inherente del lenguaje para efectuar defragmentaciones del monticulo. Un 
defragmentador del monticulo complica las cosas dado que tiene que mover peda- 
zos de memoria, y por lo tanto, hacer que los punteros dejen de apuntar a valores 
validos. Algunos entornos operativos vienen con este tipo de facilidades pero obli- 
gan al programador a utilizar manejadores de memoria especiales en lugar de pun¬ 
teros (estos manipuladores se pueden convertir temporalmente en punteros una vez 
bloqueada la memoria para que el defragmentador del monticulo no la modifique). 
Tambien podemos construir nosotros mismos uno de estos artilugios, aunque no es 
una tarea sencilla. 

Cuando creamos una variable en la pila en tiempo de compilation, el mismo com¬ 
pilador es quien se encarga de crearla y liberar la memoria ocupada por ella auto- 
maticamente. Conoce exactamente el tamano y la duracion de este tipo de variables 
dada por las reglas de ambito. Sin embargo, en el caso de las variables almacenadas 
dinamicamente, el compilador no poseera information ni del tamano requerido por 
las mismas, ni de su duracion. Esto significa que el compilador no puede encargarse 
de liberar automaticamente la memoria ocupada por este tipo de variables y de aqui 
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que el responsable de esta tarea sea el programador (o sea usted). Para esto se debe 
utilizar delete, lo cual le indica al administrador del montlculo que ese espacio de 
memoria puede ser utilizado por proximas llamadas a new. En nuestra libreria de 
ejemplo, el lugar logico para esta tarea es la funcion cleanup () dado que alii es 
donde se deben realizar todas las labores de finalizacion de uso del objeto. 

Para probar la libreria se crean dos Cstash, uno que almacene enteros y otro para 
cadenas de 80 caracteres: 

//: C04:CLibTest.cpp 
//{L} CLib 

// Test the C-like library 

#include "CLib.h" 

#include <fstream> 

#include <iostream> 

#include <string> 

#include <cassert> 
using namespace std; 

int main() { 

// Define variables at the beginning 
// of the block, as in C: 

CStash intStash, stringStash; 

int i; 
char* cp; 

ifstream in; 
string line; 
const int bufsize = 80; 

// Now remember to initialize the variables: 

initialize(SintStash, sizeof(int) ) ; 
for(i = 0; i < 100; i++) 
add(SintStash, &i) ; 
for(i =0; i < count(SintStash); i++) 

cout << "fetch (SintStash, " << i << ") = " 

<< * (int*) fetch(SintStash, i) 

<< endl; 

// Holds 80-character strings: 

initialize(SstringStash, sizeof(char) *bufsize); 
in.open("CLibTest.cpp"); 
assert(in); 

while (getline(in, line)) 

add(&stringStash, line.c_str()); 

1 = 0 ; 

while ((cp = (char* )fetch(SstringStash,i++))!=0) 
cout << "fetch(SstringStash, " << i << ") = " 

<< cp << endl; 
cleanup(SintStash); 
cleanup(SstringStash) ; 

} ///:~ 


Dado que debemos respetar la sintaxis de C, todas las variables se deben declarar 
al comienzo de main (). Obviamente, no nos podemos olvidar de inicializar todas 
las variables Cstash mas adelante en el bloque main(), pero antes de usarlas, llaman- 
do a initialize (). Uno de los problemas con las librerias en C es que uno debe 
asegurarse de convencer al usuario de la importancia de las funciones de inicializa- 
cion y destruccion. jHabra muchos problemas si estas funciones se omiten! Lamen- 
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tablemente el usuario no siempre se preguntara si la inicializacion y el limpiado de 
los objetos son obligatorios. Elios le daran importancia a lo que ellos quieren hacer 
y no nos daran tanta importancia a nosotros (el programador de la libreria) cuando 
les digamos «jHey! jespera un poco! jDebes hacer esto primero!». Otro problema que 
puede presentarse es el hecho de que algunos usuarios quieran inicializar los ele- 
mentos (datos internos) de una estructura por su cuenta. En C no hay un mecanismo 
para prevenir este tipo de conductas (mas presagios de los temas que vendran...). 

La intStash se va llenando con enteros mientras que el stringStash se va 
llenando con arrays de caracteres. Estos arrays de caracteres son producidos leyen- 
do el archivo fuente CLibTest. cpp y almacenando las lineas de este archivo en 
el string line. Obtenemos la representation «puntero a caracter» de line con el 
metodo c_str (). 

Una vez cargados los Stash ambos se muestran en pantalla. intStash se impri- 
me usando un bucle for en el cual se usa count () para determinar la cantidad de 
elementos. El stringStash se muestra utilizando un bucle while dentro del cual 
se va llamando a f etch (). Cuando esta funcion devuelve cero se rompe el bucle ya 
que esto significara que se han sobrepasado los limites de la estructura. 

El lector tambien pudo haber visto un molde adicional en la linea: 

cp = (char*)fetch(SstringStash, i++) 


Esto se debe a la comprobacion estricta de tipos en C++, que no permite asignar 
un void * a una variable de cualquier tipo, mientras que C si lo hubiera permitido. 


4.1.2. Malas suposiciones 

Antes de abordar los problemas generales de la creacion de una libreria C, dis- 
cutiremos otro asunto importante que se debe tener claro. Frjese que el archivo de 
cabecera CLib. h debe incluirse en cada archivo fuente que haga referencia al tipo 
CStash ya que el compilador no puede adivinar que aspecto tiene la estructura. Sin 
embargo, si puede adivinar el aspecto de una funcion. Aunque eso pueda parecer 
una ventaja, veremos que en realidad, es un grave problema de C. 

Aunque siempre deberia declarar las funciones incluyendo un archivo de cabe¬ 
cera, en C las declaraciones de funciones no son esenciales. En este lenguaje (pero no 
en C++), es posible llamar a una funcion que no ha sido declarada. Un buen com¬ 
pilador seguramente avisara de que deberiamos declarar la funcion antes de usarla, 
pero nos permitira seguir dado que no es obligatorio hacerlo en C estandar. Esta es 
una practica peligrosa ya que el compilador puede asumir que una funcion que ha 
sido llamada con un int como argumento, tenga un int como argumento cuando, en 
realidad, es un float. Como veremos, esto puede producir errores que pueden ser 
muy dificiles de depurar. 

Se dice que cada archivo de implementation C (los archivos de extension . c) es 
una unidad de traduccion (translation unit). El compilador se ejecuta independien- 
temente sobre cada unidad de traduccion ocupandose, en ese momento, solamente 
en ese archivo. Por eso, la informacion que le demos al compilador por medio de los 
archivos de cabecera es muy importante dado que determina la forma enq que ese 
archivo se relaciona con las demas partes del programa. Por eso motivo, las decla¬ 
raciones en los archivos de cabecera son particularmente importantes dado que, en 
cada lugar que se incluyen, el compilador sabra exactamente que hacer. Por ejem- 
plo, si en un archivo de cabecera tenemos la declaration void func (float) , si 
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llamamos a func () con un int como argumento, el compilador sabra que debera 
convertir el int a float antes de pasarle el valor a la funcion (a esto se le llama promo- 
cion de tipos). Sin la declaracion, el compilador asumiria que la funcion tiene la forma 
func (int) , no realizaria la promocion y pasaria, por lo tanto, datos incorrectos a la 
funcion. 

Para cada unidad de traduccion, el compilador crea un archivo objeto, de exten¬ 
sion . o, . ob j o algo por el estilo. Estos archivos objeto, junto con algo de codigo de 
arranque se unens por el enlazador (linker) para crear el programa ejecutable. Todas 
las referencias externas se deben resolver en la fase de enlazado. En archivos como 
CLibTest. cpp, se declaran funciones como initialize ( ) y fetch () (o sea, se 
le informa al compilador que forma tienen estas funciones), pero no se definen. Es- 
tan definidas en otro lugar, en este caso en el archivo CLib. cpp. De ese modo, las 
llamadas que se hacen en CLibTest. cpp a estas funciones son referencias externas. 
Cuando se unen los archivos objeto para formar el programa ejecutable, el enlazador 
debe, para cada referenda externa no resuelta, encontrar la direccion a la que hace 
referenda y reemplazar cada referenda externa con su direccion correspondiente. 

Es importante senalar que en C, estas referencias externas que el enlazador busca 
son simples nombres de funciones, generalmente precedidos por un guion bajo. De 
esta forma, la unica tarea del enlazador es hacer corresponder el nombre de la fun¬ 
cion que se llama, con el cuerpo (definicion, codigo) de la funcion del archivo objeto, 
en el lugar exacto de la llamada a dicha funcion. Si, por ejemplo, accidentalmente 
hacemos una llamada a una funcion que el compilador interprete como func ( int) 
y existe una definicion de funcion para func (float) en algun archivo objeto, el 
enlazador vera _f unc en un lugar y _f unc en otro, por lo que pensara que todo esta 
bien. En la llamada a f unc () se pasara un int en la pila pero el cuerpo de la funcion 
func ( ) esperara que la pila tenga un float. Si la funcion solo lee el valor de este dato 
y no lo escribe, la pila no sufrira datos. De hecho, el supuesto float leido de la pila 
puede tener algo de sentido: la funcion seguira funcionando aunque sobre basura, 
y es por eso que los fallos originadas por esta clase de errores son muy dificiles de 
encontrar. 


4.2. </Que tiene de malo? 

Somos seres realmente destinados a la adaptacion, incluso a las que quiza no de- 
beriamos adaptarnos. El estilo de la libreria CStash ha sido un modelo a seguir para 
los programadores en C durante mucho tiempo. Sin embargo, si nos ponemos a exa- 
minarla por un momento, nos daremos cuenta de que utilizar esta libreria puede 
resultar incomodo. Cuando la usamos debemos, por ejemplo, pasar la direccion de 
la estructura a cada funcion de la libreria. Por eso, cuando leemos el codigo, los me- 
canismos de la libreria se mezclan con el significado de las llamadas a las funciones, 
lo cual dificulta la comprecsion del programa. 

Sin embargo, uno de los mayores obstaculos al trabajar con librerias en C es el 
problema llamado conflicto de nombres (name clashes). C trabaja con un unico espacio 
de nombres de funciones. Esto significa que, cuando el enlazador busca por el nom¬ 
bre de una funcion, lo hace en una unica lista de nombres maestra. Ademas, cuando 
el compilador trabaja sobre una unidad de traduccion, un nombre de funcion solo 
puede hacer referenda a una unica funcion con ese nombre. 

Supongamos que compramos dos librerias de diferentes proveedores y que cada 
libreria consta de una estructura que debe inicializar y destruir. Supongamos que ca¬ 
da proveedor ha decidido nombrar a dichas operaciones initialize () y clean¬ 
up (). ^Como se comportaria el compilador si incluyeramos los archivos de cabecera 
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de ambas librerias en la misma unidad de traduccion? Afortunadamente, el compi- 
lador C dara un mensaje de error diciendonos que hay una incoherencia de tipos en 
las listas de argumentos de ambas declaraciones. No obstante, aunque no incluya- 
mos los archivos de cabecera en la unidad de traduccion igual tendremos problemas 
con el enlazador. Un buen enlazador detectara y avisara cuando se produzca uno 
de estos conflictos de nombres. Sin embargo, hay otros que simplemente tomaran 
el primer nombre de la funcion que encuentren, buscando en los archivos objeto en 
el orden en el que fueron pasados en la lista de enlazado. (Este comportamiento se 
puede considerar como una ventaja ya que permite reemplazar las funciones de las 
librerias ajenas con funciones propias.) 

En cualquiera de los dos casos, llegamos a la conclusion de que en C es imposi- 
ble usar dos bibliotecas en las cuales existan funciones con nombres identicos. Para 
solucionar este problema, los proveedores de librerias en C ponen un prefijo unico a 
todas las funciones de la libreria. Ennuestro ejemplo, las funciones initialize () 
y cleanup () habria que renombrarlas como CStash_initialize () y CStas- 
h_cleanup (). Esta es una tecnica logica: decoramos los nombres de las funciones 
con el nombre de la estructura sobre la cual trabajan. 

Este es el momento de dirigir nuestros pasos a las primeras nociones de construc¬ 
tion de clases en C++. Como el lector ha de saber, las variables declaradas dentro de 
una estructura no tienen conflictos de nombres con las variables globales. ^Por que, 
entonces, no aprovechar esta caracteristica de las variables para evitar los conflictos 
de nombres de funciones declarandolas dentro de la estructura sobre la cual operan? 
O sea, ^por que no hacer que las funciones sean tambien miembros de las estructu- 
ras? 


4.3. El objeto basico 

Nuestro primer paso sera exactamente ese. Meter las funciones C++ dentro de 
las estructuras como «funciones miembro». Este es el aspecto que tiene la estructura 
una vez realizados estos cambios de la version C de la CStash a la version en C++, a 
la que llamaremos Stash: 

//: C04:CppLib.h 

// C-like library converted to C++ 

struct Stash { 

int size; // Size of each space 

int quantity; // Number of storage spaces 
int next; // Next empty space 

// Dynamically allocated array of bytes: 

unsigned char* storage; 

// Functions! 

void initialize (int size); 

void cleanup(); 

int add (const void* element); 

void* fetch (int index); 

int count () ; 

void inflate (int increase); 

}; ///:- 


La primera diferencia que puede notarse es que no se usa typedef . A diferencia 
de C que requiere el uso de typedef para crear nuevos tipos de datos, el compila- 
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dor de C++ hara que el nombre de la estructura sea un nuevo tipo de dato automa- 
ticamente en el programa (tal como los nombres de tipos de datos int, char, float y 
double). 

Todos los datos miembros de la estructura estan declarados igual que antes; sin 
embargo, ahora las funciones estan declaradas dentro del cuerpo de la struct. Mas 
aun, frjese que el primer argumento de todas las funciones ha sido eliminado. En 
C++, en lugar de forzar al usuario a que pase la direccion de la estructura sobre la 
que trabaja una funcion como primer argumento, el compilador hara este trabajo, 
secretamente. Ahora solo debe preocuparse por los argumentos que le dan sentido a 
lo que la funcion hace y no de los mecanismos infernos de la funcion. 

Es importante darse cuenta de que el codigo generado por estas funciones es el 
mismo que el de las funciones de la libreria al estilo C. El numero de argumentos es 
el mismo (aunque no se le pase la direccion de la estructura como primer argumen¬ 
to, en realidad si se hace) y sigue existiendo un unico cuerpo (definicion) de cada 
funcion. Esto ultimo quiere decir que, aunque declare multiples variables 

Stash A, B, C; 

no existiran multiples definiciones de, por ejemplo, la funcion add (), una para 
cada variable. 

De modo que el codigo generado es casi identico al que hubiese escrito para una 
version en C de la libreria, incluyendo la «decoracion de nombres» ya mencionada 
para evitar los conflictos de nombres, nombrando a las funciones Stash_initi- 
alize (), Stash_cleanup () y demas. Cuando una funcion esta dentro de una 
estructura, el compilador C++ hace lo mismo y por eso, una funcion llamada in¬ 
itialize () dentro de una estructura no estara en conflicto con otra funcion in¬ 
itialize () dentro de otra estructura o con una funcion initialize () global. 
De este modo, en general no tendra que preocuparse por los conflictos de nombres 
de funciones - use el nombre sin decoracion. Sin embargo, habra situaciones en las 
que deseara especificar, por ejemplo, esta initialize ( ) pertenece a la estructura 
Stash y no a ninguna otra. En particular, cuando defina la funcion, necesita espe- 
cificar a que estructura pertenece para lo cual, en C++ cuenta con el operador : : 
llamado operador de resolucion de ambito (ya que ahora un nombre puede estar en 
diferentes ambitos: el del ambito global o dentro del ambito de una estructura. Por 
ejemplo, si quiere referirse a una funcion initialize () que se encuentra dentro 
de la estructura Stash lo podra hacer con la expresion Stash: initialize (int 
size) . A continuacion podra ver como se usa el operador de resolucion de ambito 
para definir funciones: 

//: C04:CppLib.cpp {0} 

// C library converted to C++ 

// Declare structure and functions: 

#include "CppLib.h" 

#include <iostream> 

#include <cassert> 
using namespace std; 

// Quantity of elements to add 
// when increasing storage: 
const int increment = 100; 

void Stash::initialize (int sz) { 

size = sz; 

quantity = 0; 


151 
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storage = 0; 
next = 0; 


int Stash::add (const void* element) { 

if (next >= quantity) // Enough space left? 

inflate(increment); 

// Copy element into storage, 

// starting at next empty space: 
int startBytes = next * size; 
unsigned char* e = (unsigned char* )element; 
for(int i = 0; i < size; i++) 

storage[startBytes + i] = e[i]; 
next++; 

return (next - 1); // Index number 


void* Stash::fetch (int index) { 

// Check index boundaries: 
assert (0 <= index); 
if (index >= next) 

return 0; //To indicate the end 
// Produce pointer to desired element: 
return &(storage[index * size]); 


int Stash::count () { 

return next; // Number of elements in CStash 

} 


void Stash::inflate (int increase) { 
assert(increase > 0) ; 

int newQuantity = quantity + increase; 
int newBytes = newQuantity * size; 
int oldBytes = quantity * size; 

unsigned char* b = new unsigned char [newBytes]; 
for(int i = 0; i < oldBytes; i++) 

b[i] = storage [i] ; // Copy old to new 
delete []storage; // Old storage 
storage = b; // Point to new memory 
quantity = newQuantity; 


void Stash::cleanup() { 

if (storage != 0) { 

cout << "freeing storage" << endl; 
delete []storage; 


} ///:~ 


Hay muchas otras cosas que difieres entre C y C++. Para empezar, el compila- 
dor requiere que declare las funciones en los archivos de cabecera: en C++ no podra 
llamar a una funcion sin haberla declarado antes y si no se cumple esta regia el com- 
pilador dara un error. Esta es una forma importante de asegurar que las llamadas 
a una funcion son consistentes entre el punto en que se llama y el punto en que se 
define. A1 forzar a declarar una funcion antes de usarla, el compilador de C++ prac- 
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ticamente se asegura de que realizara esa declaration por medio de la inclusion de 
un fichero de cabecera. Ademas, si tambien incluye el mismo fichero de cabecera en 
el mismo lugar donde se defines las funciones, el compilador verificara que las de- 
claraciones del archivo cabecera y las definiciones coinciden. Puede decirse entonces 
que, de algun modo, los ficheros de cabecera se vuelven un repositorio de validation 
de funciones y permiten asegurar que las funciones se usan de modo consistente en 
todas las unidades de traduction del proyecto. 

Obviamente, las funciones globales se pueden seguir declarando a mano en aque- 
llos lugares en las que se definen y usan (Sin embargo, esta practica es tan tediosa 
que esta en desuso.) De cualquier modo, las estructuras siempre se deben declarar 
antes de ser usadas y el mejor lugar para esto es un fichero de cabecera, exceptuando 
aquellas que queremos esconder intencionalmente en otro fichero. 

Se puede ver que todas las funciones miembro (metodos) tienen casi la misma 
forma que sus versiones respectivas en C. Las unicas diferencias son su ambito de 
resolution y el hecho de que el primer argumento ya no aparece explicito en el pro- 
totipo de la funcion. Por supuesto que sigue ahi ya que la funcion debe ser capaz de 
trabajar sobre una variable struct en particular. Sin embargo, frjese tambien que, 
dentro del metodo, la selection de esta estructura en particular tambien ha desapa- 
recido! Asi, en lugar de decir s->size = sz; ahora dice size = sz ; eliminando 
el tedioso s-> que en realidad no aportaba nada al significado semantico de lo que 
estaba escribiendo. Aparentemente, el compilador de C++ esta realizando estas ta- 
reas por el programador. De hecho, esta tomando el primer argumento «secreto» (la 
direction de la estructura que antes tenia que pasar a mano) y aplicandole el selector 
de miembro (->) siempre que escribe el nombre de uno de los datos miembro. Eso 
significa que, siempre y cuando este dentro de la definition de una metodo de una 
estructura puede hacer referencia a cualquier otro miembro (incluyendo otro meto¬ 
do) simplemente dando su nombre. El compilador buscara primero en los nombres 
locales de la estructura antes de buscar en versiones mas globales de dichos nom¬ 
bres. El lector podra descubrir que esta caracteristica no solo agiliza la escritura del 
codigo, sino que tambien hace la lectura del mismo mucho mas sencilla. 

Pero que pasaria si, por alguna razon, cjuisiera hacer referencia a la direction de 
memoria de la estructura. En la version en C de la libreria esta se podia obtener 
facilmente del primer argumento de cualquier funcion. En C++ la cosa es mas con¬ 
sistente: existe la palabra reservada this que produce la direction de la variable 
struct actual. Es el equivalente a la expresion s de la version en C de la libreria. De 
modo que, podremos volver al estilo de C escribiendo 

this->size = Size; 

El codigo generado por el compilador sera exactamente el mismo por lo que no 
es necesario usar this en estos casos. Ocasionalmente, podra ver por ahi codigo 
donde la gente usa this en todos sitios sin agregar nada al significado del codigo 
(esta practica es indicio de programadores inexpertos). Por lo general, this no se usa 
muy a menudo pero, cuando se necesite siempre estara alii (en ejemplos posteriores 
del libro vera mas sobre su uso). 

Queda aun un ultimo tema que tocar. En C, se puede asignar un void * a cualquier 
otro puntero, algo como esto: 

int i = 10; 

void* vp = &i; // OK tanto en C como en C++ 
int* ip = vp; // oSlo aceptable en C 
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y no habra ningun tipo de queja por parte de compilador. Sin embargo, en C++, 
lo anterior no esta permitido. <d’or que? Porque C no es tan estricto con los tipos de 
datos y permite asignar un puntero sin un tipo especifico a un puntero de un tipo 
bien determinado. No asi C++, en el cual la verification de tipos es critica y el com¬ 
pilador se detendra quejandose en cualquier conflicto de tipos. Esto siempre ha sido 
importante, pero es especialmente importante en C++ ya que dentro de las estructu- 
ras puede hacer metodos. Si en C++ estuviera permitido pasar punteros a estructuras 
con impunidad en cuanto a conflicto de tipos, jpodria terminar llamando a un meto- 
do de una estructura en la cual no existiera dicha funcion miembro! Una verdadera 
formula para el desastre. Asi, mientras C++ si deja asignar cualquier puntero a un 
void * (en realidad este es el proposito original del puntero a void: que sea suficien- 
temente largo como para apuntar a cualquier tipo) no permite asignar un void * a 
cualquier otro tipo de puntero. Para ello se requiere un molde que le indique tanto 
al lector como al compilador que realmente quiere tratarlo como el puntero destino. 

Y esto nos lleva a discutir un asunto interesante. Uno de los objetivos importantes 
de C++ es poder compilar la mayor cantidad posible de codigo C para asi, permi- 
tir una facil transition al nuevo lenguaje. Sin embargo, eso no significa, como se ha 
visto que cualquier segmento de codigo que sea valido en C, sera permitido automa- 
ticamente en C++. Hay varias cosas que un compilador de C permite hacer que son 
potencialmente peligrosas y propensas a generar errores (vera ejemplos de a lo largo 
de libro). El compilador de C++ genera errores y avisos en este tipo de situaciones 
y como vera eso es mas una ventaja que un obstaculo a pesar de su naturaleza res- 
trictiva. jDe hecho, existen muchas situaciones en las cuales tratara de detectar sin 
exito un error en C y cuando recompiles el programa con un compilador de C++ este 
avisa exactamente de la causa del problema!. En C, muy a menudo ocurre que para 
que un programa funcione correctamente, ademas de compilarlo, luego debe hacer 
que ande. jEn C++, por el contrario, vera que muchas veces si un programa compila 
correctamente es probable que funcione bien! Esto se debe a que este ultimo lenguaje 
es mucho mas estricto respecto a la comprobacion de tipos. 

En el siguiente programa de prueba podra apreciar cosas nuevas con respecto a 
como se utiliza la nueva version de la Stash: 

//: C04:CppLibTest.cpp 

//{L} CppLib 

// Test of C++ library 

#include "CppLib.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

int main () { 

Stash intStash; 

intStash.initialize (sizeof(int)) ; 

for(int i = 0; i < 100; i++) 
intStash.add(&i); 

for (int j = 0; j < intStash.count (); j-+) 
cout << "intStash.fetch(" << j << ") = " 

<< * (int* )intStash.fetch ( j) 

<< endl; 

// Holds 80-character strings: 

Stash stringStash; 

const int bufsize = 80; 


154 
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stringStash.initialize (sizeof(char) * bufsize); 
ifstream in ( "CppLibTest.cpp"); 
assure(in, "CppLibTest.cpp"); 
string line; 

while (getline(in, line)) 

stringStash.add(line.c_str()) ; 
int k = 0; 

char* cp; 

while ((cp = (char* )stringStash.fetch (k++) ) != 0) 

cout << "stringStash.fetch(" << k << ") = " 

<< cp << endl; 
intStash.cleanup(); 
stringStash.cleanup(); 

} ///:- 


Una de las cosas que el lector habra podido observar en el codigo anterior es que 
las variables se definen «al vuelo», o sea (como se introdujo en el capitulo anterior) 
en cualquier parte de un bloque y no necesariamente -como en C- al comienzo de los 
mismos. 

El codigo es bastante similar al visto en CLibTest. cpp con la diferencia de que, 
cuando se llama a un metodo, se utiliza el operador de seleccion de miembro '.' 
precedido por el nombre de la variable. Esta es una sintaxis conveniente ya que imita 
a la seleccion o acceso de un da to miembro de una estructura. La unica diferencia es 
que, al ser un metodo, su llamada implica una lista de argumentos. 

Tal y como se dijo antes, la llamada que el compilador hace genera realmente es 
mucho mas parecida a la llamada a la funcion de la libreria en C. Considere la deco- 
racion de nombres y el paso del puntero this: la llamada en C++ de intStash . - 
initialize (sizeof (int) , 100) se transformara en algo parecido a Stash_- 
initialize (SintStash, sizeof (int) , 100). Si el lector sepregunta que es 
lo que sucede realmente debajo del envoltorio, deberia recordar que el compilador 
original de C++ cfront de AT&T producia codigo C como salida que luego debia ser 
compilada con un compilador de C para generar el ejecutable. Este metodo permitia 
a cfront ser rapidamente portable a cualquier maquina que soportara un compila¬ 
dor estandar de C y ayudo a la rapida difusion de C++. Dado que los compiladores 
antiguos de C++ tenian que generar codigo C, sabemos que existe una manera de 
representar sintaxis C++ en C (algunos compiladores de hoy en dia aun permiten 
generar codigo C). 

Comparando con CLibTest. cpp observara un cambio: la introduccion del fi- 
chero de cabecera require . h. He creado este fichero de cabecera para realizar una 
comprobacion de errores mas sofisticada que la que proporciona assert (). Contie- 
ne varias funciones incluyendo la llamada en este ultimo ejemplo, assure () que se 
usa sobre ficheros. Esta funcion verifica que un fichero se ha abierto exitosamente y 
en caso contrario reporta un aviso a la salida de error estandar (por lo que tambien 
necesita el nombre del fichero como segundo argumento) y sale del programa. Las 
funciones de require . h se usan a lo largo de este libro especialmente para asegu- 
rar que se ha indicado la cantidad correcta de argumentos en la linea de comandos y 
para verificar que los ficheros se abren correctamente. Las funciones de require . h 
reemplazan el codigo de deteccion de errores repetitivo y que muchas veces es cau¬ 
sa de distracciones y mas aun, proporcionan mensajes utiles para la deteccion de 
posibles errores. Estas funciones se explican detalladamente mas adelante. 
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4.4. </Que es un objeto? 

Ahora que ya se ha visto y discutido un ejemplo incial es hora de retroceder para 
definir la terminologia. El acto de introducir funciones en las estructuras es el eje 
central del cambio que C++ propone sobre C, e eso introduce una nueva forma de 
ver las estructuras: como conceptos. En C, una estructura (struct) es tan solo una 
agrupacion de datos: una manera de empaquetar datos para que se puedan tratar 
como un grupo. De esta forma, cuesta hacerse a la idea de que representan algo mas 
que una mera conveniencia de programacion. Las funciones que operan sobre esas 
estructuras estan sueltas por ahi. Sin embargo, con las funciones dentro del mismo 
paquete que los datos, la estructura se convierte en una nueva criatura, capaz de re- 
presentar las caracteristicas (como hacen las structs de C) y los comportamientos. 
El concepto de objeto, una entidad independiente y bien limitada que puede recor- 
dar y actuar, se sugiere a si mismo como definicion. 

En C++, un objeto es simplemente una variable, y la definicion mas purista es 
«una region de almacenamiento» (que es una forma mas especifica para decir «un 
objeto debe tener un unico identificador» el cual, en el caso de C++, es una direccion 
unica de memoria). Es un lugar en el cual se pueden almacenar datos y eso implica 
tambien operaciones que pueden actuar sobre esos datos. 

Desafortunadamente no existe una consistencia completa entre los distintos len- 
guajes cuando se habla de estos terminos, aunque son aceptados bastante bien. Tam¬ 
bien se podran encontrar discrepancias sobre lo que es un lenguaje orientado a ob- 
jetos, aunque parece haber un consenso razonable hoy en dia. Hay lenguajes basados 
en objetos, que cuentan con estructuras-con-funciones como las que ha visto aqui de 
C++. Sin embargo, esto es tan solo una parte de lo que denomina un lenguaje orienta¬ 
do a objetos, y los lenguajes que solamente llegan a empaquetar las funciones dentro 
de las estructuras son lenguajes basados en objetos y no orientados a objetos. 


4.5. Tipos abstractos de datos 

La habilidad para empaquetar datos junto con funciones permite la creacion de 
nuevos tipos de datos. Esto se llama a menudo encapsulation 3 Un tipo de dato exis- 
tente puede contener varias piezas de datos empaquetadas juntas. Por ejemplo, un 
float tiene un exponente, una mantissa y un bit de signo. Le podemos pedir que 
haga varias cosas: sumarse a otro float o a un int, etc. Tiene caracteristicas y compor- 
tamiento. 

La definicion de Stash crea un nuevo tipo de dato. Se le pueden agregar nuevos 
elementos (add ()), sacar (fetch ()) y agrandarlo (inflate ()). Se puede crear uno 
escribiendo Stash s; igual que cuando se crea un float diciendo float x;. Un 
Stash tambien tiene caracteristicas y un comportamiento bien determinado. Aunque 
actue igual que un tipo de dato predefinido como float se dice que Stash es un tipo 
abstracto de dato tal vez porque permite abstraer un concepto desde el espacio de 
los problemas al espacio de la solucion. Ademas, el compilador de C++ lo tratara 
exactamente como a un nuevo tipo de dato y si, por ejemplo, declara una funcion que 
acepta un Stash como argumento, el compilador se asegurara de que no se le pase 
otra cosa a la funcion. De modo que se realiza el mismo nivel de comprobacion de 
tipos tanto para los tipos abstractos de datos (a veces tambien llamados tipos definidos 
por el usuario) como para los tipos predefinidos. 


3 Este termino puede causar debates. Algunas personas lo utilizan tal y como esta definido aqul, 
aunque otras lo usan para describir el control de acceso, termino que se discutira en el siguiente capitulo. 
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Sin embargo, notara inmediatamente una diferencia en la forma en que se rea- 
lizan las operaciones sobre los objetos. Se hace objeto . funcionMiembro (list- 
aArgumentos) o sea, «se llama a un metodo de un objeto». Pero en la jerga de la 
orientacion a objetos, eso tambien se denomina «enviar un mensaje a un objeto». De 
modo que para una Stash s, en esta jerga la sentencia s . add (& i ) le «envia un 
mensaje a s» diciendole «anadete (add ()) esto». De hecho, la programacion orien- 
tada a objetos se puede resumir en la siguiente frase: enviar mensajes a objetos. Real- 
mente, ^eso es todo lo que se hace? crear un monton de objetos y enviarles mensajes. 
El truco, obviamente, es entender que son en nuestro problema los objetos y los men¬ 
sajes, pero una vez que se ha cumplido esa etapa, la implementation en C++ sera 
sorprendentemente directa. 


4.6. Detalles del objeto 

Una pregunta que surge a menudo en seminarios es «^Como de grande es un 
objeto y que pinta tiene?» La respuesta es «mas o menos lo que esperas de un st¬ 
ruct en C». De hecho, el codigo que produce el compilador de C para un struct 
C (sin adornos C++) normalmente es exactamente el mismo que el producido por 
un compilador C++. Eso tranquiliza a aquellos programadores C que dependan de 
los detalles de tamano y distribucion de su codigo, y que por alguna razon accedan 
directamente a los bytes de la estructura en lugar de usar identificadores (confiar en 
un tamano y distribucion particular para una estructura no es portable). 

El tamano de una struct es la combination de los tamanos de todos sus miem- 
bros. A veces cuando el compilador crea una struct, anade bytes extra para hacer 
que los limites encajen limpiamente - eso puede incrementar la eficiencia de la ejecu- 
cion. En el Capitulo 14, vera como en algunos casos se anaden punteros «secretos» a 
la estructura, pero no tiene que preocuparse de eso ahora. 

Puede determinar el tamano de una struct usando el operador sizeof. Aqui 
tiene un pequeno ejemplo: 

//: C04:Sizeof.cpp 
// Sizes of structs 

#include "CLib.h" 

#include "CppLib.h" 

#include <iostream> 

using namespace std; 

struct A { 

int i[10 0] ; 

} ; 


struct B { 
void f(); 

}; 


void B: 

: :f ( 

) U 



int main() 

{ 



cout 

<< 

"sizeof 

struct A = " << 

sizeof (A) 


<< 

" bytes" 

<< endl; 


cout 

<< 

"sizeof 

struct B = " << 

sizeof (B) 


<< 

" bytes" 

<< endl; 


cout 

<< 

" sizeof 

CStash in C = " 
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<< 

cout << 
<< 


} ///:~ 


sizeof (CStash) << " bytes" << endl; 

"sizeof Stash in C++ = " 

sizeof (Stash) << " bytes" << endl; 


En mi maquina (los resultados pueden variar) el primer resultado produce 200 
porque cada int ocupa 2 bytes. La struct B es algo anomalo porque es una struct 
sin atributos. En C, eso es ilegal, pero en C++ necesitamos la posibilidad de crear una 
struct cuya unica tarea es ofrecer un ambito a nombres de funciones, por eso esta 
permitido. Aun asi, el segundo resultado es un sorprendente valor distinto de cero. 
En versiones anteriores del lenguage, el tamano era cero, pero aparecia una situation 
incomoda cuando se creaban estos objetos: tenian la misma direccion que el objeto 
creado antes que el, y eran indistinguibles. Una de las reglas fundamentales de los 
objetos es que cada objeto debe tener una direccion unica, asi que las estructuras sin 
atributos siempre tendran tamano minimo distinto de cero. 

Las dos ultimas sentencias sizeof muestran que el tamano de la estructura en 
C++ es el mismo que en la version en C. C++ intenta no anadir ninguna sobrecarga 
innecesaria. 


4.7. Conveciones para los ficheros de cabecera 

Cuando se crea una struct que contiene funciones miembro, se esta creando un 
nuevo tipo de dato. En general, se intenta que ese tipo sea facilmente accesible. En 
resumen, se quiere que la interfaz (la declaration) este separada de la implmentacion 
(la definition de los metodos) de modo que la implementation pueda cambiar sin 
obligar a recompilar el sistema completo. Eso se consigue poniendo la declaration 
del nuevo tipo en un fichero de cabecera. 

Cuando yo aprendi a programar en C, el fichero de cabecera era un misterio para 
mi. Muchos libros de C no hacen hincapie, y el compilador no obliga a hacer la de¬ 
claration de las funciones, asi que parecia algo opcional la mayor parte de las veces, 
excepto cuando se declaraban estrucutras. En C++ el uso de los ficheros de cabecera 
se vuelve claro como el cristal. Son practicamente obligatorios para el desarrollo de 
programas sencillos, y en ellos podra information muy especifica: declaraciones. El 
fichero de cabecera informa al compilador de lo que hay disponible en la libreria. 
Puede usar la libreria incluso si solo se dispone del fichero de cabecera y el fichero 
objeto o el fichero de libreria; no necesita disponer del codigo fuente del fichero cpp. 
En el fichero de cabecera es donde se guarda la especificacion de la interfaz. 

Aunque el compilador no lo obliga, el mejor modo de construir grandes proyec- 
tos en C es usar librerias; colecciones de funciones asociadas en un mismo modulo 
objeto o libreria, y usar un fichero de cabecera para colocar todas las declaraciones de 
las funciones. Es de rigor en C++, Podria meter cualquier funcion en una libreria C, 
pero el tipo abstracto de dato C++ determina las funciones que estan asociadas por 
medio del acceso comun a los datos de una struct. Cualquier funcion miembro 
debe ser declarada en la declaration de la struct; no puede ponerse en otro lugar. 
El uso de librerias de funciones fue fomentado en C y institucionalizado en C++. 


4.7.1. Importancia de los ficheros de cabecera 

Cuando se usa funcion de una libreria, C le permite la posibilidad de ignorar el 
fichero de cabecera y simplemente declarar la funcion a mano. En el pasado, la gente 
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hada eso a veces para acelerar un poquito la compilation evitando la tarea de abrir 
e incluir el fichero (eso no supone ventaja alguna con los compiladores modernos). 
Por ejemplo, la siguiente es una declaration extremadamente vaga de la funcion p- 

rintf() (de < stdio . h>): 

printf (...); 


Estos puntos suspensivos 4 especifican una lista de argumentos variable 5 , que di¬ 
ce: la printf () tiene algunos argumentos, cada uno con su tipo, pero no se sabe 
cuales. Simplemente, coge los argumentos que veas y aceptalos. Usando este tipo de 
declaration, se suspenden todas las comprobaciones de errores en los argumentos. 

Esta practica puede causar problemas sutiles. Si declara funciones «a mano», en 
un fichero puede cometer un error. Dado que el compilador solo vera las declaracio- 
nes hechas a mano en ese fichero, se adaptara al error. El programa enlazara correc- 
tamente, pero el uso de la funcion en ese fichero sera defectuoso. Se trata de un error 
dificil de encontrar, y que se puede evitar facilmente usando el fichero de cabecera 
correspondiente. 

Si se colocan todas las declaraciones de funciones en un fichero de cabecera, y se 
incluye ese fichero alii donde se use la funcion se asegurara una declaration consis- 
tente a traves del sistema completo. Tambien se asegurara de que la declaration y la 
definition corresponden incluyendo el fichero de cabecera en el fichero de definition. 

Si declara una struct en un fichero de cabecera en C++, debe incluir ese fichero 
alii donde se use una struct y tambien donde se definan los metodos de la s- 
truct. El compilador de C++ devolvera un mensaje de error si intenta llamar a 
una funcion, o llamar o definir un metodo, sin declararla primero. Imponiendo el 
uso apropiado de los ficheros de cabecera, el lenguaje asegura la consistencia de las 
librerias, y reduce el numero de error forzando que se use la misma interface en 
todas partes. 

El fichero de cabecera es un contrato entre el programador de la libreria y el que 
la usa. El contrato describe las estructuras de datos, expone los argumentos y valores 
de retorno para las funciones. Dice, «Esto es lo que hace mi libreria». El usuario nece- 
sita parte de esta information para desarrollar la aplicacion, y el compilador necesita 
toda ella para generar el codigo correcto. El usuario de la struct simplemente in¬ 
cluye el fichero de cabecera, crea objetos (instancias) de esa struct, y enlaza con el 
modulo objeto o libreria (es decir, el codigo compilado) 

El compilador impone el contrato obligando a declarar todas las estruturas y fun¬ 
ciones antes que puedan ser usadas y, en el caso de metodos, antes de ser definidos. 
De ese modo, se le obliga a poner las declaraciones en el fichero de cabecera e in- 
cluirlo en el fichero en el que se definen los metodos y en los ficheros en los que se 
usen. Como se incluye un unico fichero que describe la libreria para todo el sistema, 
el compilador puede asegurar la consistencia y evitar errores. 

Hay ciertos asuntos a los que debe prestar atencion para organizar su codigo 
apropiadamente y escribir ficheros de cabecera eficaces. La regia basica es «unica- 
mente declaraciones», es decir, solo information para el compiladore pero nada que 
requiera alojamiento en memoria ya sea generando codigo o creando variables. Esto 
es asi porque el fichero de cabecera normalmente se incluye en varias unidades de 

4 (N. de T. ellipsis) en ingles) 

5 Para escribir una definition de funcion que toma una lista de argumentos realmente variable, debe 
usar varargs, aunque se deberia evitar en C++. Puede encontar information detallada sobre el uso de 
varnrgs en un manual de C. 
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traduccion en un mismo proyecto, y si el almacenamiento para un identificador se 
pide en mas de un sitio, el enlazador indicara un error de definicion multiple (esta 
es la regia de definicion linica de C++: Se puede declarar tantas veces como se quiera, 
pero solo puede haber una definicion real para cada cosa). 

Esta norma no es completamente estricta. Si se define una variable que es «file 
static» (que tiene visibilidad solo en un fichero) dentro de un fichero de cabecera, 
habra multiples instancias de ese dato a lo largo del proyecto, pero no causara un 
colision en el enlazador 6 . Basicamente, debe evitar cualquier cosa en los ficheros de 
cabecera que pueda causar una ambigiiedad en tiempo de enlazado. 


4.7.2. El problema de la declaracion multiple 

La segunda cuestion respecto a los ficheros de cabecera es esta: cuando se pone 
una declaracion de struct en un fichero de cabecera, es posible que el fichero sea 
incluido mas de una vez en un programa complicado. Los iostreams son un buen 
ejemplo. Cada vez que una struct hace E/S debe incluir uno de los ficheros de 
cabecera iostream. Si el fichero cpp sobre el que se esta trabajando utiliza mas de 
un tipo de struct (tipicamente incluyendo un fichero de cabecera para cada una), 
se esta corriendo el riesgo de incluir el fichero <isotream> mas de una vez y re- 
declarar los iostreams. 

El compilador considera que la redeclaration de una estructura (eso es aplicable 
tando a las struct como a las class) es un error, dado que de otro modo, deberia 
permitir el uso del mismo nombre para tipos diferentes. Para evitar este error cuando 
se incluyen multiples ficheros de cabecera, es necesario dar algo de inteligencia a los 
ficheros de cabecera usando el preprocesador (los ficheros de cabecera estandares 
como <iostream> tambien tienen esta «inteligencia»). 

Tanto C como C++ permiten redeclarar una funcion, siempre que las dos decla- 
raciones coincidan, pero ni en ese caso se permite la redeclaration de una estructura. 
En C++ esta regia es especialmente importante porque si el compilador permitiera 
la redeclaration de una estructura y las dos declaraciones difirieran, <+’11 a 1 deberia 
usar? 

El problema de la redeclaration se agrava un poco en C++ porque cada tipo de 
dato (estructura con funciones) generalmente tiene su propio fichero de cabecera, y 
hay que incluir un fichero de cabecera en otro si se quiere crear otro tipo de dato que 
use al primero. Es probable que en algun fichero cpp de su proyecto, que se incluyan 
varios ficheros que incluyan al mismo fichero de cabecera. Durante una compilation 
simple, el compilador puede ver el mismo fichero de cabecera varias veces. A menos 
que se haga algo al respecto, el compilador vera la redeclaration de la estructura e 
informara un error en tiempo de compilation. Para resolver el problema, necesitara 
saber un poco mas acerca del preprocesador. 


4.7.3. Las directivas del preprocesador #define, #ifndef y 
#endif 

La directiva de preprocesador #define se puede usar para crear banderas en 
tiempo de compilation. Tiene dos opciones: puede simplemente indicar al preproce¬ 
sador que la bandera esta definida, sin especificar un valor: 


6 Sin embargo, en C++ estandar «file static» es una caracteristica obsoleta. 
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#define FLAG 


o puede darle un valor (que es la manera habitual en C para definir una constan- 
te): 


#define PI 3.14159 


En cualquier caso, ahora el preprocesador puede comprobar si la etiqueta ha sido 
definida: 

#ifdef FLAG 


Esto producira un resultado verdadero, y el codigo que sigue al #ifdef se in- 
cluira en el paquete que se envia al compilador. Esta inclusion acaba cuando el pre¬ 
procesador encuentra la sentencia: 

tendif 


o 


#endif // FLAG 


Cualquier cosa despues de #endif en la misma linea que no sea un comentario 
es ilegal, incluso aunque algunos compiladores lo acepten. Los pares #ifdef/ten¬ 
dif se pueden anidar. 

El complementario de # define es tundef (abreviacion de «un-define» quehara 
que una sentencia #ifdef que use la misma variable produzca un resultado falso. 
tundef tambien causara que el preprocesador deje de usar una macro. El comple¬ 
mentario de tifdef es #if ndef, que producira verdadero si la etiqueta no ha sido 
definida (este es el que usaremos en los ficheros de cabecera). 

Hay otras caracteristicas utiles en el preprocesador de C. Consulte la documen- 
tacion de su preprocesador para ver todas ellas. 


4.7.4. Un estandar para los ficheros de cabecera 

En cada fichero de cabecera que contiene una estructura, primero deberia com¬ 
probar si ese fichero ya ha sido includo en este fichero cpp particular. Hagalo com- 
probando una bandera del preprocesador. Si la bandera no esta definida, el fichero 
no se ha incluido aun, y se deberia definir la bandera (de modo que la estructura no 
se pueda redeclarar) y declarar la estructura. Si la bandera estaba definida entonces 
el tipo ya ha sido declarado de modo que deberia ignorar el codigo que la declara. 
Asi es como deberia ser un fichero de cabecera: 

tifndef HEADER_FLAG 
tdefine HEADER_FLAG 
// Escriba la odeclaracin faqu... 
tendif // HEADER_FLAG 
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Como puede ver, la primera vez que se incluye el fichero de cabecera, los con- 
tenidos del fichero (incluyendo la declaracion del tipo) son incluidos por el prepro- 
cesador. Las demas veces que se incluya -en una unica unidad de programacion- la 
declaracion del tipo sera ignorada. El nombre HEADER_FLAG puede ser cualquier 
nombre unico, pero un estandar fiable a seguir es poner el nombre del fichero de 
cabecera en mayusculas y reemplazar los puntos por guiones bajos (sin embargo, el 
guionbajo al comienzo esta reservado para nombres del sistema). Este es un ejemplo: 

//: C04:Simple.h 

// Simple header that prevents re-definition 

#ifndef SIMPLE_H 
#define SIMPLE_H 

struct Simple { 

int i, j,k; 

initialized { i = j = k = 0; } 

} ; 

#endif // SIMPLE_H ///:- 


Aunque el SIMPLE_H despues de #endif esta comentado y es ignorado por el 
preprocesador, es util para documentation. 

Estas sentencias del preprocesador que impiden inclusiones multiples se deno- 
minan a menudo guardas de inclusion (include guards) 


4.7.5. Espacios de nombres en los ficheros de cabecera 

Notara que las directivas using estan presentes en casi todos los ficheros cpp de 
esto libro, normalmente en la forma: 

using namespace std; 


Como std es el espacio de nombres que encierra la libreria Estandar C++ al com- 
pleto, esta directiva using en particular permite que se puedan usar los nombres de 
la libreria Estandar C++. Sin embargo, casi nunca vera una directiva using en un 
fichero de cabecera (al menos, no fuera de un bloque). La razon es que la directiva 
using elimina la proteccion de ese espacio de nombres en particular, y el efecto du¬ 
ra hasta que termina la unidad de compilation actual. Si pone una directiva using 
(fuera de un bloque) en un fichero de cabecera, significa que esta perdida de «protec- 
cion del espacio de nombres» ocurrira con cualquier fichero que incluya este fichero 
de cabecera, lo que a menudo significa otros ficheros de cabecera, es muy facil acabar 
«desactivando» los espacios de nombres en todos sitios, y por tanto, neutralizando 
los efectos beneficiosos de los espacios de nombres. 

En resumen: no ponga directivas using en ficheros de cabecera. 


4.7.6. Uso de los ficheros de cabecera en proyectos 

Cuando se construye un proyecto en C++, normalmente lo creara poniendo jun¬ 
tos un monton de tipos diferentes (estructuras de datos con funciones asociadas). 
Normalmente pondra la declaracion para cada tipo o grupo de tipos asociados en 
un fichero de cabecera separado, entonces definira las funciones para ese tipo en una 
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unidad de traduccion. Cuando use ese tipo, debera incluir el fichero de cabecera para 
efectuar las declaraciones apropiadamente. 

A veces ese patron se seguira en este libro, pero mas a menudo los ejemplos 
seran muy pequenos, as! que todo - la declaracion de las estructuras, la definicion 
de las funciones, y la funcion main () - pueden aparecer en un unico fichero. Sin 
embargo, tenga presente que deberia usar ficheros separados y ficheros de cabecera 
para aplicaciones reales. 


4.8. Estructuras anidadas 

La conveniencia de coger nombres de funciones y datos fuera del espacio de nom- 
bre global es aplicable a las estructuras. Puede anidar una estructura dentro de otra 
estructura, y por tanto guardar juntos elementos asociados. La sintaxis de declara¬ 
cion es la que podria esperarse, tal como puede ver en la siguiente estructura, que 
implementa una pila como una lista enlazada simple de modo que «nunca» se queda 
sin memoria. 

// : C04:Stack . h 

// Nested struct in linked list 

#ifndef STACK_H 
#define STACK_H 

struct Stack { 
struct Link { 
void* data; 

Link* next; 

void initialize (void* dat, Link* nxt) ; 

}* head; 

void initialize(); 
void push (void* dat); 
void* peek(); 
void* pop(); 
void cleanup(); 

} ; 

#endif // STACK_H ///:- 


La struck anidada se llama Link, y contiene un puntero al siguiente Link en 
la lista y un puntero al dato almacenado en el Link. Si el siguiente puntero es cero, 
significa que es el ultimo elemento de la lista. 

Frjese que el puntero head esta definido a la derecha despues de la declaracion 
de la struct Link, es lugar de una definicion separada Link* head. Se trata de 
una sintaxis que viene de C, pero que hace hincapie en la importancia del punto y 
coma despues de la declaracion de la estructura; el punto y coma indica el fin de una 
lista de definiciones separadas por comas de este tipo de estructura (Normalmente 
la lista esta vacia.) 

La estructura anidada tiene su propia funcion initialize (), como todas las 
estructuras hasta el momenta, para asegurar una inicializacion adecuada. Stac- 
k tiene tanto funcion initialice () como cleanup (), ademas de push (), que 
toma un puntero a los datos que se desean almacenar (asume que ha sido alojado 
en el monticulo), y pop (), que devuelve el puntero data de la cima de la Stack y 
elimina el elemento de la cima. (El que hace pop () de un elemento se convierte en 



'Volumenl" — 2012/1/12 — 13:52 — page 164 — #202 


Capitulo 4. Abstraction de Datos 


responsable de la destruction del objeto apuntado por data.) La funcion peak () 
tambien devuelve un puntero data a la cima de la pila, pero deja el elemento en la 

Stack. 

Aqui se muestran las definiciones de los metodos: 

//: C04:Stack.cpp {0} 

// Linked list with nesting 

#include "Stack.h" 

#include "../require.h" 
using namespace std; 

void 

Stack::Link::initialize (void* dat, Link* nxt) { 
data = dat; 
next = nxt; 

} 


void Stack::initialize () { head = 0; } 

void Stack::push (void* dat) { 

Link* newLink = new Link; 
newLink->initialize(dat, head); 
head = newLink; 

} 


void* Stack::peek() { 

require(head != 0, "Stack empty"); 
return head->data; 

} 


void* Stack::pop() { 

if (head == 0) return 0; 
void* result = head->data; 
Link* oldHead = head; 
head = head->next; 
delete oldHead; 
return result; 

} 


void Stack::cleanup () { 

require(head == 0, "Stack not empty"); 

} ///:~ 


La primera definicion es particularmente interesante porque muestra como se de¬ 
fine un miembro de una estructura anidada. Simplemente se usa un nivel adicional 
de resolucion de ambito para especificar el nombre de la struct interna. Stack : - 
: Link : : initialize () toma dos argumentos y los asigna a sus atributos. 

Stack: initialize () asgina cero a head, de modo que el objeto sabe que 
tiene una lista vacia. 

Stack: :push() toma el argumento, que es un puntero a la variable a la que se 
quiere seguir la pista, y la apila en la Stack. Primero, usa new para pedir alojamiento 
para el Link que se insertara enla cima. Entonces llama a la funcion initialize () 
para asignar los valores apropiados a los miembres del Link. Fijese que el siguiente 
puntero se asigna al head actual; entonces head se asigna al nuevo puntero Link. 
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Esto apila eficazmente el Link en la cima de la lista. 

Stack : : pop () captura el puntero data en la cima actual de la Stack; entonces 
mueve el puntero head hacia abajo y borra la anterior cima de la Stack, finalmente 
devuelve el puntero capturado. Cuando pop () elemina el ultimo elemento, head 
vuelve a ser cero, indicando que la Stack esta vacia. 

Stack : : cleanup () realmenteno hace ninguna limpieza. En su lugar, establece 
una politica firme que dice «el programador cliente que use este objeto Stack es 
responsable de des-apilar todos los elementos y borrarlos». require () se usa para 
indicar que ha ocurrido un error de programacion si la Stack no esta vacia. 

^Por que no puede el destructor de Stack responsabilizarse de todos los objetos 
que el programador cliente no des-apilo? El problema es que la Stack esta usan- 
do punteros void, y tal como se vera en el Capitulo 13 usar delete para un void* 
no libera correctamente. El asunto de «quien es el responsable de la memoria» no 
siempre es sencillo, tal como veremos en proximos capitulos. 

Un ejemplo para probar la Stack: 

//: C04:StackTest.cpp 

//{L} Stack 

//{T} StackTest.cpp 

// Test of nested linked list 

#include "Stack.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

int main(int argc, char* argv[]) { 

requireArgs(argc, 1); // File name is argument 
ifstream in(argv[l]); 
assure (in, argv[l]); 

Stack textlines; 

textlines.initialize(); 

string line; 

// Read file and store lines in the Stack: 
while(getline(in, line)) 

textlines.push(new string(line)); 

// Pop the lines from the Stack and print them: 
string* s; 

while((s = (string*)textlines.pop()) != 0) { 

cout << *s << endl; 

delete s; 

} 

textlines.cleanup(); 

} ///:- 


Es similar al ejemplo anterior, pero en este se apilan lineas de un fichero (como 
punteros a cadena) en la Stack y despues los des-apila, lo que provoca que el fichero 
sea imprimido en orden inverso. Fijese que pop () devuelve un void* que debe ser 
moldeado a string* antes de poderse usar. Para imprimir una cadena, el puntero es 
dereferenciado. 
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Como textlines se llena, el contenido de line se «clona» para cada push- 
() creando un new string (line) . El valor devuelto por la expresion new es un 
puntero al nuevo string que fue creado y al que se ha copiado la informacion de la 
line. Si se hubiera pasado directamente la direccion de line a push (), la Stack 
se llenaria con direcciones identicas, todas apuntando a line. Mas adelante en ese 
libro aprendera mas sobre este proceso de «clonacion». 

El nombre del fichero se toma de linea de comando. Para garantizar que hay su- 
ficientes argumentos en la linea de comando, se usa una segunda funcion del fichero 
de cabecera require . h: requireArgs () que compara argc con el numero de ar¬ 
gumentos deseado e imprime un mensaje de error y termina el programa si no hay 
suficientes argumentos. 


4.8.1. Resolucion de ambito global 

El operador de resolucion de ambito puede ayudar en situaciones en las que el 
nombre elegido por el compilador (el nombre «mas cercano») no es el que se quiere. 
Por ejemplo, suponga que tiene una estructura con un identificador local a, y quiere 
seleccionar un identificador global a desde dentro de un metodo. El compilador, 
por defecto, elegira el local, de modo que es necesario decirle que haga otra cosa. 
Cuando se quiere especificar un nombre global usando la resolucion de ambito, debe 
usar el operador sin poner nada delante de el. A continuacion aparece un ejemplo 
que muestra la resolucion de ambito global tanto para una variable como para una 
funcion: 


//: C04:Scoperes.cpp 
// Global scope resolution 

int a; 
void f() {} 

struct S { 
int a; 
void f(); 

} ; 


void S::f 

: :f 0 ; 

::a++; 
a—; 


) { 

// Would be recursive otherwise! 
// Select the global a 
// The a at struct scope 


int raain() { S s; f(); } ///:- 


Sin resolucion de ambito en S : : f (), el compilador elegiria por defecto las ver- 
siones miembro para f () y a. 


4.9. Resumen 

En este capitulo, ha aprendido lo fundamental de C++: que puede poner funcio- 
nes dentro de las estructuras. Este nuevo tipo de estructura se llama tipo abstracto de 
dato, y las variables que se crean usando esta estructura se llaman objetos, o instan- 
cias, de ese tipo. Invocar un metodo de una objeto se denomina enviar un mensaje al 
objeto. La actividad principal en la programacion orientada a objetos es el envio de 



'Volumenl" — 2012/1/12 — 13:52 — page 167 — #205 


4.10. Ejercicios 


mensajes a objetos. 

Aunque empaquetar datos y funciones juntos es un benificio significativo para 
la organization del codigo y hace la librerla sea mas facil de usar porque previene 
conflictos de nombres ocultando los nombres, hay mucho mas que se puede hacer 
para tener programacion mas segura en C++. En el proximo capitulo, aprendera 
como proteger algunos miembros de una struct para que solo el programador 
pueda manipularlos. Esto establece un lrrnite claro entre lo que puede cambiar el 
usuario de la estructura y lo que solo el programador puede cambiar. 


4.10. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. En la librerla C estandar, la funcion puts () imprime un array de caracteres a 
la consola (de modo que puede escribir puts ( "Hola" )). Escriba un program 
C que use puts ( ) pero que no incluya <stdio . h> o de lo contrario declare 
la funcion. Compile ese programa con su compilador de C. (algunos compi- 
ladores de C++ no son programas distintos de sus compiladores de C, es ese 
caso puede que necesite averiguar que option de lrnea de comando fuerza una 
compilation C.) Ahora compllelo con el compilador C++ y preste atencion a la 
diferencia. 

2. Cree una declaration de struct con un unico metodo, entonces cree una defi¬ 
nition para ese metodo. Cree un objeto de su nuevo tipo de dato, e invoque el 
metodo. 

3. Cambie su solution al Ejercicio 2 para que la struct sea declarada en un fiche- 
ro de cabecera convenientemente «guardado», con la definition en un fichero 
cpp y el main () en otro. 

4. Cree una struct con un unico atributo de tipo entero, y dos funciones globa- 
les, cada una de las cuales acepta un puntero a ese s t ru ct . La primera funcion 
tiene un segundo argumento de tipo entero y asigna al entero del struct el 
valor del argumento, la segunda muestra el entero de la struct. Prueba las 
funciones. 

5. Repita el Ejercicio 4 pero mueva las funcion de modo que sean metodos de la 
struct, y pruebe de nuevo. 

6. Cree una clase que (de forma redundante) efectue la selection de atributos y 
una llamada a metodo usando la palabra reservada this (que indica a la di¬ 
rection del objeto actual) 

7. Cree una Stach que mantenga doubles. Rellenela con 25 valores double, des¬ 
pues muestrelos en consola. 

8. Repita el Ejercicio 7 con Stack. 

9. Cree un fichero que contenga una funcion f () que acepte un argumento entero 
y lo imprima en consola usando la funcion printf ( ) de <stdio> escribien- 
do: print f (" %d\n", i) donde i es el entero que desea imprimir. Cree un 
fichero separado que contenga main (), y este fichero declare f ( ) pero acep- 
tando un argumento float. Invoque f () desde main (). Intente compilar y en- 
lazar el programa con el compilador C++ y vea que ocurre. Ahora compile y 
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enlace el programa usando el compilador C, y vea que ocurre cuando se ejecu- 
ta. Explique el comportamiento. 

10. Averigiie como generar lenguaje ensamblador con su compilador C y C++. Es- 
criba una funcion en C y una st ruct con un unico miembro en C++. Genere la 
salida en lenguaje ensamblador para cada una de ellas y encuentre los nombres 
de ambas funciones, de modo que pueda ver que tipo de «decoracion» aplica 
el compilador a dichos nombres. 

11. Escriba un programa con codigo condicionalmente-compilado en main (), pa¬ 
ra que cuando se defina un valor del preprocesador, se muestre un mensaje, 
pero cuando no se defina, se imprima otra mensaje distinto. Compile este ex- 
perimentando con un #def ine en el programa, despues averigiie la forma de 
indicar al compilador definiciones de preprocesador en la linea de comandos y 
experimente con ello. 

12. Escriba un programa que use assert () con un argumento que siempre sea 
falso (cero) y vea que ocurre cuando lo ejecuta. Ahora compilelo con #def ine 
NDEBUG y ejecutelo de nuevo para ver la diferencia. 

13. Cree un tipo abstracto de da to que represente un cinta de video en una tienda 
de alquiler. Considere todos los datos y operaciones que serian necesarias para 
que el tipo Video funcione con el sistema de gestion de la tienda. Incluya un 
metodo print () que muestre information sobre el Video 

14. Cree un objeto Pila que almacene objetos Video del Ejercicio 13. Cree varios 
objetos Video, guardelos en la Stack y entonces muestrelos usando Video- 
::print (). 

15. Escriba un programa que muestre todos los tamanos de los tipos de datos fun- 
damentales de su computadora usando sizeof. 

16. Modifique Stash para usar vector<char> como estructura de datos subya- 
cente. 

17. Cree dinamicamente espacio de almacenamiento para los siguiente tipos usan¬ 
do new: int, long, un array de 100 char, un array de 100 float. Muestre sus 
direcciones y liberelos usando delete. 

18. Escriba una funcion que tome un argumento char’ 1 '. Usando new, pida aloja- 
miento dinamico para un array de char con un tamano igual al argumento 
pasado a la funcion. Usando indexation de array, copie los caracteres del argu¬ 
mento al array dinamico (no olvide el terminador nulo) y devuelva el puntero 
a la copia. En su main (), pruebe la funcion pasando una cadena estatica entre 
comillas, despues tome el resultado y paselo de nuevo a la funcion. Muestre 
ambas cadenas y punteros para poder ver que tienen distinta ubicacion. Me- 
diante delete libere todo el almacenamiento dinamico. 

19. Haga un ejemplo de estructura declarada con otra estructura dentro (un es¬ 
tructura anidada). Declare atributos en ambas structs, y declare y defina 
metodos en ambas structs. Escriba un main () que pruebe los nuevos tipos. 

20. ^Como de grande es una estructura? Escriba un trozo de codigo que muestre 
el tamano de varias estructuras. Cree estructuras que tengan solo atributos y 
otras que tengan atributos y metodos. Despues cree una estructura que no ten- 
ga ningun miembro. Muestre los tamanos de todas ellas. Explique el motivo 
del tamano de la estructura que no tiene ningun miembro. 
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21. C++ crea automaticamente el equivalente de typedef para structs, tal como 
ha visto en este capitulo. Tambien lo hace para las enumeraciones y las uniones. 
Escriba un pequeno programa que lo demuestre. 

22. Cree una Stack que maneje Stashes. Cada Stash mantendra cinco lineas 
procedentes de un fichero. Cree las Stash usando new. Lea un fichero en su 
Stack, despues muestrelo en su forma original extrayendolo de la Stack. 

23. Modifique el Ejercicio 22 de modo que cree una estructura que encapsule la 
Stack y las Stash. El usuario solo deberia anadir y pedir lineas a traves de 
sus metodos, pero debajo de la cubierta la estructura usa una Stack(pila) de 
Stashes. 

24. Cree una struct que mantenga un int y un puntero a otra instancia de la 
misma struct. Escriba una funcion que acepte como parametro la direccion 
de una de estas struct y un int indicando la longitud de la lista que se desea 
crear. Esta funcion creara una cadena completa de estas struct (una lista enla- 
zada), empezando por el argumento (la cabeza de la lista), con cada una apun- 
tando a la siguiente. Cree las nuevas struct usando new, y ponga la posicion 
(que numero de objeto es) en el int. En la ultima struct de la lista, ponga un 
valor cero en el puntero para indicar que es el ultimo. Escriba una segunda 
funcion que acepte la cabeza de la lista y la recorra hasta el final, mostrando 
los valores del puntero y del int para cada una. 

25. Repita el ejercicio 24, pero poniendo las funciones dentro de una struct en 
lugar de usar struct y funciones «crudas». 
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5: Ocultar la implementation 

Una libreria C tfpica contiene una estructura y una serie de fun- 
ciones que actuan sobre esa estructura. Hasta ahora hemos visto co- 
mo C++ toma funciones conceptualmente asociadas y las asocia li- 

teralmente poniendo la declaration de la funcion dentro del dominio de la es¬ 
tructura, cambiando la forma en que se invoca a las funciones desde las estructuras, 
eliminando el paso de la direction de la estructura como primer parametro, y ana- 
diendo un nuevo tipo al programa (de ese modo no es necesario crear un typedef 
para la estructura). 

Todo esto son mejoras, le ayuda a organizar su codigo haciendolo mas facil de 
escribir y leer. Sin embargo, hay otros aspectos importantes a la hora de hacer que 
las librerlas sean mas sencillas en C++, especialmente los aspectos de seguridad y 
control. Este capltulo se centra en el tema de la frontera de las estructuras. 


5.1. Establecer los limites 

En toda relation es importante tener fronteras que todas las partes respeten. 
Cuando crea una librerla, establece una relation con el programador cliente que la usa 
para crear un programa u otra librerla. 

En una estructura de C, como casi todo en C, no hay reglas. Los programadores 
cliente pueden hacer lo que quieran con esa estructura, y no hay forma de forzar 
un comportamiento particular. Por ejemplo, aunque vio en el capltulo anterior la 
importancia de las funciones llamadas initialize () y cleanup (), el programa¬ 
dor cliente tiene la option de no llamarlas. (Veremos una forma mejor de hacer lo en 
el capltulo siguiente.) Incluso si realmente prefiere que el programador cliente no 
manipule directamente algunos miembros de su estructura, en C no hay forma de 
evitarlo. Todo esta expuesto al todo el mundo. 

Hay dos razones para controlar el acceso a los miembros. La primera es no de¬ 
jar que el programador cliente ponga las manos sobre herramientas que no deberla 
tocar, herramientas que son necesarias para los entresijos del tipo definido, pero no 
parte del interfaz que el programador cliente necesita para resolver sus problemas 
particulares. Esto es realmente una ventaja para los programadores cliente porque 
as! pueden ver lo que es realmente importante para ellos e ignorar el resto. 

La segunda razon para el control de acceso es permitir al disenador de la librerla 
cambiar su funcionamiento interno sin preocuparse de como afectara al programa¬ 
dor cliente. En el ejemplo Stack del capltulo anterior, podrla querer solicitar espacio 
de almacenamiento en grandes trozos, para conseguir mayor velocidad, en vez de 
crear un nuevo espacio cada vez que un elemento es anadido. Si la interfaz y la im¬ 
plementation estan claramente separadas y protegidas, puede hacerlo y forzar al 
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programador cliente solo a enlazar de nuevo sus programas. 


5.2. Control de acceso en C++ 

C++ introduce tres nuevas palabras clave para establecer las fronteras de una 
estructura: public, private y protected. Su uso y significado es bastante cla- 
ro. Los especificadores de acceso se usan solo en la declaration de las estructuras, y 
cambian las fronteras para todas las declaraciones que los siguen. Cuando use un 
especificador de acceso, debe ir seguido de «:» 

public significa que todas las declaraciones de miembros que siguen estaran 
accesibles para cualquiera. Los miembros publicson como miembros de una es¬ 
tructura. Por ejemplo, las siguientes declaraciones de estructuras son identicas: 

//: C05:Public.cpp 

// Public is just like C's struct 

struct A { 
int i; 
char j; 
float f; 
void func(); 

} ; 


void A::func() {} 

struct B { 
public: 
int i; 
char j; 
float f; 
void func (); 


void B :: func() {} 


int main() 

A a; B b ; 
a . i = b. i 
a. j = b.j 
a . f = b. f 

a. func () ; 

b. func () ; 
} ///:~ 


= 1 ; 

= ' c' ; 

= 3.14159; 


La palabra clave private, por otro lado, significa que nadie podra acceder a ese 
miembro excepto usted, el creador del tipo, dentro de los metodos de ese tipo. pri¬ 
vate es una pared entre usted y el programador cliente; si alguien intenta acceder a 
un miembro private, obtendra un error en tiempo de compilation. En struct B 
en el ejemplo anterior, podria querer hacer partes de la representation (es decir, los 
atributos) ocultos, accesibles solo a usted: 

//: C05:Private.cpp 
// Setting the boundary 
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struct b { 
private: 
char j; 
float f; 
public: 
int i; 

void func (); 


void B: :func () { 

i = 0; 
j = 'O'; 
f = 0.0; 


int main () 

{ 

B b; 


b. i = 1 ; 

// OK, public 

//! b.j = 

' 1 ' ; // Illegal, 

//! b.f = 

1.0; // Illegal, 

} ///:- 



private 

private 


Aunque func () puede acceder a cualquier miembro de B (pues func () en un 
miembro de B, garantizando asi automaticamente el acceso), una funcion global ordi- 
naria como main () no puede. Por supuesto tampoco miembros de otras estructuras. 
Solo las funciones que pertenezcan a la declaration de la estructura (el «contrato») 
tendran acceso a miembros private. 

No hay un orden fijo para los especificadores de acceso, y pueden aparecer mas 
de una vez. Afectan a todos los miembros declarados despues de ellos hasta el si- 
guiente especificador. 


5.2.1. protected 

Es el ultimo que nos queda por ver, protected actua como private, con una 
exception de la que hablaremos mas tarde: estructuras heredadas (que no pueden 
acceder a lo miembros privados) si tienen acceso a los miembros protected. Todo 
esto se vera mas claramente en el capitulo 14 cuando veamos la herencia. Con lo que 
sabe hasta ahora puede considerar protected igual que private. 


5.3. Amigos (friends) 

^Que pasa si explicitamente se quiere dar acceso a una funcion que no es miem¬ 
bro de la estructura? Esto se consigue declarando la funcion como friend dentro 
de la declaration de la estructura. Es importante que la declaration de una funcion 
friend se haga dentro de la declaration de la estructura pues usted (y el compila- 
dor) necesita ver la declaration de la estructura y todas las reglas sobre el tamaho y 
comportamiento de ese tipo de dato. Y una regia muy importante en toda relation 
es, «<;Quien puede acceder a mi parte privada?» 

La clase controla que codigo tiene acceso a sus miembros. No hay ninguna ma- 
nera magica de «colarse» desde el exterior si no eres friend; no puedes declarar 



'Volumenl" — 2012/1/12 — 13:52 — page 174 — #212 


Capltulo 5. Ocultar la implementation 


una nueva clase y decir, «Hola, soy friend de Bob» y esperar ver los miembros 

private y protected de Bob. 

Puede declarar una funcion global como friend, tambien puede declarar un 
metodo de otra estructura, o incluso una estructura completa, como friend. Aqul 
hay un ejemplo: 

//: C05:Friend.cpp 

// Friend allows special access 

// Declaration (incomplete type specification): 

struct X; 

struct Y { 
void f(X*) ; 

} ; 

struct X { // Definition 

private: 

int i; 
public: 

void initialize(); 

friend void g(X*, int); // Global friend 
friend void Y::f(X*); // Struct member friend 

friend struct Z; // Entire struct is a friend 

friend void h(); 

} ; 


void X::initialize () { 

i = 0; 

} 

void g (X* x, int i) { 

x->i = i; 

} 

void Y::f(X* x) { 
x->± = 47; 

} 

struct Z { 
private: 

int j; 
public: 

void initialize(); 
void g (X* x) ; 

} ; 


void Z::initialize () { 

j = 99; 

} 


void Z :: g(X* x) { 
x->i += j; 

} 


void h() { 

X x; 
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x.i = 100; // Direct data manipulation 

} 

int main() { 

X x; 

Z z ; 

z.g(&x); 

} ///:- 


struct Y tiene un metodo f () que modifica un objeto de tipo X. Aqui hay 
un poco de lio pues en C++ el compilador necesita que usted declare todo antes 
de poder hacer referenda a ello, asi struct Y debe estar declarado antes de que 
su metodo Y: : f (X*) pueda ser declarado como friend en struct X. Pero para 
declarar Y : : f (X*), struct X debe estar declarada antes! 

Aqui vemos la solution. Dese cuenta de que Y : : f (X* ) toma como argumento 
la direccion de un objeto de tipo X. Esto es fundamental pues el compilador siempre 
sabe como pasar una direccion, que es de un tamano fijo sin importar el tipo, aunque 
no tenga information del tamano real. Si intenta pasar el objeto completo, el compi¬ 
lador necesita ver la definicion completa de X, para saber el tamano de lo que quiere 
pasar y como pasar lo, antes de que le permita declarar una funcion como Y : : g (X). 

Pasando la direccion de un X, el compilador le permite hacer una identification de 
tipo incompleta de X antes de declarar Y: : f (X* ). Esto se consigue con la declaration: 

struct X; 


Esta declaration simplemente le dice al compilador que hay una estructura con 
ese nombre, asi que es correcto referirse a ella siempre que solo se necesite el nombre. 

Ahora, en struct X, la funcion Y : : f (X* ) puede ser declarada como friend 
sin problemas. Si intenta declararla antes de que el compilador haya visto la especi- 
ficacion completa de Y, habria dado un error. Esto es una restriction para asegurar 
consistencia y eliminar errores. 

Fijese en las otras dos funciones friend. La primera declara una funcion global 
ordinaria g() como friend. Pero g() no ha sido declarada antes como global!. 
Se puede usar friend de esta forma para declarar la funcion y darle el estado de 
friend simultaneamente. Esto se extiende a estructuras completas: 

friend struct Z; 


es una especificacion incompleta del tipo Z, y da a toda la estructura el estado de 

friend. 


5.3.1. Amigas anidadas 

Hacer una estructura anidada no le da acceso a los miembros privados. Para con- 
seguir esto, se debe: primero, declarar (sin definir) la estructura anidada, despues 
declararla como friend, y finalmente definir la estructura. La definicion de la es¬ 
tructura debe estar separada de su declaration como friend, si no el compilador la 
veria como no miembro. Aqui hay un ejemplo: 
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//: C05:NestFriend.cpp 
// Nested friends 

#include <iostream> 

#include <cstring> // raemset() 

using namespace std; 
const int sz = 20; 

struct Holder { 
private: 

int a[s z]; 

public: 

void initialize(); 
struct Pointer; 
friend struct Pointer; 
struct Pointer { 
private: 

Holder* h; 
int * p; 
public: 

void initialize(Holder* h); 

// Move around in the array: 

void next (); 
void previous(); 
void top (); 
void end(); 

// Access values: 
int read(); 
void set (int i); 

} ; 

} ; 

void Holder::initialize () { 

memset(a, 0, sz * sizeof(int) ); 

} 

void Holder::Pointer::initialize(Holder* rv) { 
h = rv; 
p = rv->a; 

} 

void Holder::Pointer::next() { 

if (p < &(h->a[sz - 1])) p++; 

} 

void Holder::Pointer::previous () { 

if (p > & (h->a[0])) p—; 

} 

void Holder::Pointer::top () { 

p = &(h->a[0]); 

} 

void Holder::Pointer::end () { 

p = &(h->a[sz - 1|); 

} 

int Holder::Pointer::read () { 

return *p; 


176 
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} 

void Holder::Pointer::set (int i) { 
*P = i; 

} 


int main () { 

Holder h; 

Holder::Pointer hp, hp2; 

int i; 

h.initialize (); 

hp. initialize(&h); 

hp2.initialize (&h); 

for(i = 0; i < sz; i++) { 

hp.set (i) ; 
hp.next (); 

} 

hp. top () ; 

hp2.end() ; 

for(i = 0; i < sz; i++) { 

cout << "hp = " << hp.read() 

<< ", hp2 = " << hp2.read() << endl; 
hp.next(); 
hp2.previous (); 

} 

} ///:- 


Una vez que Pointer esta declarado, se le da acceso a los miembros privados 
de Holder con la sentencia: 

friend Pointer; 

La estructura Holder contiene un array de enteros y Pointer le permite acceder 
a ellos. Como Pointer esta fuertemente asociada con Holder, es comprensible que 
sea una estructura miembro de Holder. Pero como Pointer es una clase separada 
de Holder, puede crear mas de una instancia en el main () y usarlas para seleccio- 
nar diferentes partes del array. Pointer es una estructura en vez de un puntero de 
C, as! que puede garantizar que siempre apuntara dentro de Holder. 

La funcion de la libreria estandar de C memset () (en <cstring>) se usa en el 
programa por conveniencia. Hace que toda la memoria a partir de una determina- 
da direccion (el primer argumento) se cargue con un valor particular (el segundo 
argumento) para n bytes a partir de la direccion donde se empezo (n es el tercer 
argumento). Por supuesto, se podria haber usado un bucle para hacer lo mismo, pe¬ 
ro memset () esta disponible, bien probada (asi que es mas factible que produzca 
menos errores), y probablemente es mas eficiente. 


5.3.2. ^Es eso puro? 

La definicion de la clase le da la pista, mirando la clase se puede saber que fun- 
ciones tienen permiso para modificar su parte privada. Si una funcion es friend, 
significa que no es miembro, pero que de todos modos se le quiere dar permiso para 
modificar la parte privada, y debe estar especificado en la definicion de la clase para 
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que todo el mundo pueda ver que esa es una de las funciones privilegiadas. 

C++ es un lenguaje orientado a objetos hibrido, no es puro, y friend fue anadi- 
do para solucionar algunos problemas que se presentaban en la practica. Es bueno 
apuntar que esto hace al lenguaje menos «puro», pues C++ fue disenado para ser 
pragmatico, no para aspirar a un ideal abstracto. 


5.4. Capa de objetos 

En el capitulo 4 se dijo que una struct escrita para un compilador C y mas tarde 
compilada en uno de C++ no cambiaria. Se referia basicamente a la estructura interna 
del objeto que surge de la struct, es decir, la posicion relativa en memoria donde se 
guardan los valores de las diferentes variables. Si el compilador C++ cambiase esta 
estructura interna, entonces el codigo escrito en C que hiciese uso del conocimiento 
de las posiciones de las variables fallaria. 

Cuando se empiezan a usar los especificadores de acceso, se cambia al universo 
del C++, y las cosas cambian un poco. Dentro de un «bloque de acceso» (un gru- 
po de declaraciones delimitado por especificadores de acceso), se garantiza que las 
variables se encontraran contiguas, como en C. Sin embargo, los bloques de acceso 
pueden no aparecer en el objeto en el mismo orden en que se declaran. Aunque el 
compilador normalmente colocara los bloques como los definio, no hay reglas so- 
bre esto, pues una arquitectura hardware especifica y/o un sistema operativo puede 
tener soporte especifico para private y protected que puede requerir que es- 
tos bloques se coloquen en lugares especificos de la memoria. La especificacion del 
lenguaje no quiere impedir este tipo de ventajas. 

Los especificadores de acceso son parte de la estructura y no afectan a los ob¬ 
jetos creados desde esta. Toda la informacion de accesos desaparece antes de que 
el programa se ejecute; en general ocurre durante la compilacion. En un programa 
en ejecucion, los objetos son «zonas de almacenamiento» y nada mas. Si realmente 
quiere, puede romper todas las reglas y acceder a la memoria directamente, como en 
C. C++ no esta disenado para prohibir hacer cosas salvajes. Solo le proporciona una 
alternativa mucho mas facil, y deseable. 

En general, no es una buena idea hacer uso de nada que dependa de la imple¬ 
mentacion cuando se escribe un programa. Cuando necesite hacerlo, encapsulelo en 
una estructura, asi en caso de tener que portarlo se podra concentrar en ella. 


5.5. La clase 

El control de acceso se suele llamar tambien ocultacion de la implementacion. Incluir 
funciones dentro de las estructuras (a menudo llama do encapsulacion 1 ) produce ti- 
pos de dato con caracteristicas y comportamiento, pero el control de acceso pone 
fronteras en esos tipos, por dos razones importantes. La primera es para establecer 
lo que el programador cliente puede y no puede hacer. Puede construir los mecanis- 
mos internos de la estructura sin preocuparse de que el programador cliente pueda 
pensar que son parte de la interfaz que debe usar. 

Esto nos lleva directamente a la segunda razon, que es separar la interfaz de la 
implementacion. Si la estructura se usa en una serie de programas, y el programador 
cliente no puede hacer mas que mandar mensajes a la interfaz publica, usted puede 
cambiar cualquier cosa privada sin que se deba modificar codigo cliente. 


1 Como se dijo anteriormente, a veces el control de acceso se llama tambien encapsulacion 
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La encapsulation y el control de acceso, juntos, crean algo mas que una estructura 
de C. Estamos ahora en el mundo de la programacion orientada a objetos, donde 
una estructura describe una clase de objetos como describiria una clase de peces o 
pajaros: Cualquier objeto que pertenezca a esa clase compartira esas caracteristicas y 
comportamiento. En esto se ha convertido la declaration de una estructura, en una 
description de la forma en la que los objetos de este tipo seran y actuaran. 

En el lenguaje OOP original, Simula-67, la palabra clave class fue usada para 
describir un nuevo tipo de da to. Aparentemente esto inspiro a Stroustrup a elegir 
esa misma palabra en C++, para enfatizar que este era el punto clave de todo el 
lenguaje: la creation de nuevos tipos de dato que son mas que solo estructuras de C 
con funciones. Esto parece suficiente justification para una nueva palabra clave. 

De todas formas, el uso de class en C++ es casi innecesario. Es identico a s- 
truct en todos los aspectos excepto en uno: class pone por defecto private, 
mientras que struct lo hace a public. Estas son dos formas de decir lo mismo: 

//: C05:Class.cpp 

// Similarity of struct and class 

struct A { 
private: 

int i , j, k; 
public: 
int f (); 

void g(); 

} ; 


int A::f () { 

return i + j + k; 

} 


void A::g() { 

i = j = k = 0; 

} 


// Identical results are produced with: 

class B { 

int i, j, k; 
public: 
int f (); 

void g(); 

} ; 


int B::f () { 

return i + j + k; 

} 


void B::g() { 

i = j = k = 0; 

} 


int main () { 

A a; 

B b; 

a. f () ; a.g() ; 

b. f () ; b.g() ; 
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} ///:~ 


La clase (class) en unconcepto OOP fundamental en C++. Es una de la palabras 
clave que no se pondran en negrita en este libro - es incomodo pues se repite mucho. 
El cambio a clases es tan importante que sospecho que Stroustrup hubiese preferido 
eliminar completamente struct, pero la necesidad de compatibilidad con C no lo 
hubiese permitido. 

Mucha gente prefiere crear clases a la manera struct en vez de a la manera 
class, pues sustituye el «por-defecto-private» de class empezando con los ele- 
mentos public: 

class X { 
public: 

void miembro_de_interfaz (); 
private: 

void miembro_privado() ; 
int representacion_interna; 

} ; 


El porque de esto es que tiene mas sentido ver primero lo que mas interesa, el pro- 
gramador cliente puede ignorar todo lo que dice private. De hecho, la unica razon 
de que todos los miembros deban ser declarados en la clase es que el compilador se- 
pa como de grande son los objetos y pueda colocarlos correctamente, garantizando 
as! la consistencia. 

De todas formas, los ejemplos en este libro pondran los miembros privados pri¬ 
mero, asl: 

class X { 

void private_function(); 
int internal_representation; 
public: 

void interface_function() ; 

} ; 


Alguna gente incluso decora sus nombres privados 

class Y { 
public: 

void f(); 
private: 

int mX; // "Self-decorated" name 

} ; 


Como mX esta ya oculto para Y, la m (de «miembro») es innecesaria. De todas 
formas, en proyectos con muchas variables globales (algo que debe evitar a toda cos¬ 
ta, aunque a veces inevitable en proyectos existentes), es de ayuda poder distinguir 
variables globales de atributos en la definition de los metodos. 
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5.5.1. Modificaciones en Stash para usar control de acce- 
so 

Tiene sentido coger el ejemplo del capitulo 4 y modificarlo para usar clases y con¬ 
trol de acceso. Dese cuenta de como la parte de la interfaz a usar en la programacion 
cliente esta claramente diferenciada, as! no hay posibilidad de que el programador 
cliente manipule accidentalmente parte de la clase que no deberia. 

//: C05:Stash.h 

// Converted to use access control 

#ifndef STASH_H 
#define STASH_H 

class Stash { 

int size; // Size of each space 

int quantity; // Number of storage spaces 
int next; // Next empty space 

// Dynamically allocated array of bytes: 

unsigned char* storage; 
void inflate (int increase); 

public: 

void initialize (int size); 
void cleanup (); 
int add (void* element); 
void* fetch (int index); 
int count () ; 

} ; 

#endif // STASH_H ///:- 


La funcion inflate () se ha hecho private porque solo es usada por la fun- 
cion add () y por tanto es parte de la implementation interna, no de la interfaz. Esto 
significa que, mas tarde, puede cambiar la implementation interna para usar un sis- 
tema de gestion de memoria diferente. 

Aparte del nombre del archivo include, la cabecera de antes es lo unico que ha 
sido cambiado para este ejemplo. El fichero de implementation y de prueba son los 
mismos. 


5.5.2. Modificar Stack para usar control de acceso 

Como un segundo ejemplo, aqui esta Stack convertido en clase. Ahora la estruc- 
tura anidada es private, lo que es bueno pues asegura que el programador cliente 
no tendra que fijarse ni depender de la representation interna de Stack: 

//: C05:Stack2.h 

// Nested structs via linked list 

#ifndef STACK2_H 
#define STACK2_H 

class Stack { 
struct Link { 
void* data; 

Link* next; 

void initialize (void* dat, Link* nxt); 
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}* head; 

public: 

void initialize(); 
void push (void* dat) ; 
void* peek(); 
void* pop(); 
void cleanup(); 

} ; 

#endif // STACK2_H ///:- 


Como antes, la implementacion no cambia por lo que no la repetimos aqul. El 
programa de prueba es tambien identico. La unica cosa que ha cambiado es la ro- 
bustez del interfaz de la clase. El valor real del control de acceso es prevenirle de 
traspasar las fronteras durante el desarrollo. De hecho, el compilador es el unico que 
conoce los niveles de proteccion de los miembros de la clase. No hay informacion 
sobre el control de acceso anadida en el nombre del miembro que llega al enlaza- 
dor. Todas las comprobaciones sobre proteccion son hechas por el compilador; han 
desaparecido al llegar a la ejecucion. 

Dese cuenta de que la interfaz presentada al programador cliente es ahora real- 
mente la de una pila. Sucede que esta implementada como una lista enlazada, pero 
usted puede cambiar esto sin afectar a la forma en que los programas cliente inter- 
actuan con ella, o (mas importante aun) sin afectar a una sola linea de su codigo. 


5.6. Manejo de clases 

El control de acceso en C++ le permite separar la interfaz de la implementacion, 
pero la ocultacion de la implementacion es solo parcial. El compilador debe ver aun 
la declaration de todas las partes del objeto para poder crearlo y manipularlo co- 
rrectamente. Podria imaginar un lenguaje de programacion que requiriese solo la in¬ 
terfaz publica del objeto y permitiese que la implementacion privada permaneciese 
oculta, pero C++ realiza comparacion de tipos estaticamente (en tiempo de compila¬ 
tion) tanto como es posible. Esto significa que se dara cuenta lo antes posible de si 
hay un error. Tambien significa que su programa sera mas eficiente. De todas formas, 
la inclusion de la implementacion privada tiene dos efectos: la implementacion es vi¬ 
sible aunque no se pueda acceder a ella facilmente, y puede causar recompilaciones 
innecesarias. 


5.6.1. Ocultar la implementacion 

Algunos proyectos no pueden permitirse tener visible su implementacion al pu¬ 
blico. Puede dejar a la vista informacion estrategica en un fichero de cabecera de una 
libreria que la compama no quiere dejar disponible a los competidores. Puede estar 
trabajando en un sistema donde la seguridad sea clave - un algoritmo de encripta- 
cion, por ejemplo - y no quiere dejar ninguna pista en un archivo de cabecera que 
pueda ayudar a la gente a romper el codigo. O puede que su libreria se encuentre en 
un ambiente «hostil», donde el programador accedera a los componentes privados 
de todas formas, usando punteros y conversiones. En todas estas situaciones, es de 
gran valor tener la estructura real compilada dentro de un fichero de implementa¬ 
cion mejor que a la vista en un archivo de cabecera. 
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5.6.2. Reducir la recompilacion 

Su entorno de programacion provocara una recompilacion de un fichero si este 
se modifica, o si se modifica otro fichero del que depende, es decir, un archivo de 
cabecera que se haya incluido. Esto significa que cada vez que se haga un cambio en 
una clase, ya sea a la interfaz publica o a las declaraciones de los miembros privados, 
se provocara una recompilacion de todo lo que incluya ese archivo de cabecera. Este 
efecto se conoce usualmente como el problema de la clase-base frdgil. Para un proyecto 
grande en sus comienzos esto puede ser un gran problema pues la implementacion 
suele cambiar a menudo; si el proyecto es muy grande, el tiempo de las compilacio- 
nes puede llegar a ser un gran problema. 

La tecnica para resolver esto se llama a veces clases manejador o el «gato de Che- 
sire» 2 - toda la informacion sobre la implementacion desaparece excepto por un 
puntero, la "sonrisa”. El puntero apunta a una estructura cuya definicion se encuen- 
tra en el fichero de implementacion junto con todas las definiciones de las funciones 
miembro. Asi, siempre que la interfaz no se cambie, el archivo de cabecera perma- 
nece inalterado. La implementacion puede cambiar a su gusto, y solo el fichero de 
implementacion debera ser recompilado y reenlazado con el proyecto. 

Aqui hay un ejemplo que demuestra como usar esta tecnica. El archivo de cabece¬ 
ra contiene solo la interfaz publica y un puntero de una clase especificada de forma 
incompleta: 

//: C05:Handle.h 
// Handle classes 

#ifndef HANDLE_H 
#define HANDLE_H 

class Handle { 

struct Cheshire; // Class declaration only 

Cheshire* smile; 

public: 

void initialize(); 
void cleanup(); 
int read(); 
void change (int) ; 

} ; 

#endif // HANDLE_H ///:- 


Esto es todo lo que el programador cliente puede ver. La linea 

struct Cheshire; 

es una especificacion de tipo incompleta o una declaracion de clase (una definicion de 
clase debe incluir el cuerpo de la clase). Le dice al compilador que Chesire es el nombre 
de una estructura, pero no detalles sobre ella. Esta es informacion suficiente para 
crear un puntero a la estructura; no puede crear un objeto hasta que el cuerpo de la 
estructura quede definido. En esta tecnica, el cuerpo de la estructura esta escondido 
en el fichero de implementacion: 


2 Este nombre se le atribuye a John Carolan, uno de los pioneros del C++, y por supuesto, Lewis 
Carroll. Esta tecnica se puede ver tambien como una forma del tipo de diseno «puente», descrito en el 
segundo volumen. 
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//: C05:Handle.cpp {0} 

// Handle implementation 

#include "Handle.h" 

#include /require.h" 

// Define Handle's implementation: 

struct Handle::Cheshire { 

int i; 

} ; 

void Handle::initialize () { 

smile = new Cheshire; 
smile->i = 0; 

} 

void Handle::cleanup() { 

delete smile; 

} 

int Handle::read() { 

return smile->i; 

} 

void Handle::change (int x) { 
smile->i = x; 

} III 


Chesire es una estructura anidada, asi que se debe ser definido con resolution de 
ambito: 

struct Handle::Cheshire { 

En Handle : : initialize (), se solicita espacio de almacenamiento para una 
estructura Chesire, y en Handle : : cleanup () se libera ese espacio. Este espacio 
se usa para almacenar todos los datos que estarlan normalmente en la section priva- 
da de la clase. Cuando compile Handle . cpp, esta definition de la estructura estara 
escondida en el fichero objeto donde nadie puede verla. Si cambia los elementos de 
Chesire, el unico archivo que debe ser recompilado es Handle . cpp pues el archivo 
de cabecera permanece inalterado. 

El uso de Handle es como el uso de cualquier clase: incluir la cabecera, crear 
objetos, y mandar mensajes. 

//: C05:UseHandle.cpp 

//{L} Handle 

II Use the Handle class 

#include "Handle.h" 

int main() { 

Handle u; 
u.initialize (); 
u.read(); 
u.change(1); 
u.cleanup (); 

} ///:~ 
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5.7. Resumen 


La unica cosa a la que el programador cliente puede acceder es a la interfaz pu- 
blica, as! que mientras la implementacion sea lo unico que cambie, el fichero anterior 
no necesita recompilarse. Asl, aunque esto no es ocultacion de implementacion per- 
fecta, es una gran mejora. 


5.7. Resumen 

El control de acceso en C++ ofrece un gran control al creador de la clase. Los 
usuarios de la clase pueden ver claramente lo que pueden usar y que puede ignorar. 
Mas importante aun es la posibilidad de asegurar que ningun programador clien¬ 
te depende de ninguna parte de la implementacion interna de la clase. Si sabe esto 
como creador de la clase, puede cambiar la implementacion subyacente con la segu- 
ridad de que ningun programador cliente se vera afectado por los cambios, pues no 
pueden acceder a esa parte de la clase. 

Cuando tenga la posibilidad de cambiar la implementacion subyacente, no solo 
podra mejorar su diseno mas tarde, tambien tiene la libertad de cometer errores. 
No importa con que cuidado planee su diseno, cometera errores. Sabiendo que es 
relativamente seguro que cometera esos errores, experimental mas, aprendera mas 
rapido, y acabara su proyecto antes. 

La interfaz publica de una clase es lo que realmente ve el programador cliente, asi 
que es la parte de la clase mas importante durante el analisis y diseno. Pero incluso 
esto le deja algo de libertad para el cambio. Si no consigue la interfaz correcta a la pri- 
mera, puede anadir mas funciones, mientras no quite ninguna que el programador 
cliente ya haya usado en su codigo. 


5.8. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Cree una clase con atributos y metodos public, private y protected. Cree 
un objeto de esta clase y vea que mensajes de compilacion obtiene cuando in- 
tenta acceder a los diferentes miembros de la clase. 

2. Escriba una estructura llamada Lib que contenga tres objetos string a, b 
y c. En main () cree un objeto Lib llamado x y asignelo ax.a, x.b yx.c. 
Imprima por pantalla sus valores. Ahora reemplace a , b y c con un array de 
cadenas s [ 3 ]. Dese cuenta de que su funcion main () deja de funcionar co¬ 
mo resultado del cambio. Ahora cree una clase, llamela Libc con tres cadenas 
como datosmiembroprivados a, by c,y metodos seta (), geta (), setb (- 
) , getb ( ) , setc () y getc () para establecer y recuperar los distintos valores. 
Escriba una funcion main () como antes. Ahora cambie las cadenas privadas 
a, b y c por un array de cadenas privado s [ 3 ]. Vea que ahora main () sigue 
funcionando. 

3. Cree una clase y una funcion friend global que manipule los datos privados 
de la clase. 
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4. Escriba dos clases, cada una de ellas con un metodo que reciba como argumen- 
to un puntero a un objeto de la otra clase. Cree instancias de ambas clases en 
main ( ) y llame a los metodos antes mencionados de cada clase. 

5. Cree tres clases. La primera contiene miembros privados, y declara como fr¬ 
iend a toda la segunda estructura y a una funcion miembro de la tercera. En 
main () demuestre que todo esto funciona correctamente. 

6. Cree una clase Hen. Dentro de esta, inserte una clase Nest. Y dentro de esta 
una clase Egg. Cada clase debe tener un metodo display (). En main (), cree 
una instancia de cada clase y llame a la funcion display () de cada una. 

7. Modifique el ejercicio 6 para que Nest y Egg contengan datos privados. De 
acceso mediante friend para que las clases puedan acceder a los contenidos 
privados de las clases que contienen. 

8. Cree una clase con atributos diseminados por numerosas secciones public, 
private y protected. Anada el metodo ShowMap () que imprima por pan- 
talla los no mb res de cada uno de esos atributos y su direccion de memoria. Si 
es posible, compile y ejecute este programa con mas de un compilador y/o or- 
denador y/o sistema operativo para ver si existen diferencias en las posiciones 
en memoria. 

9. Copie la implementacion y ficheros de prueba de Stash del capitulo 4 para as! 
poder compilar y probar el Stash . h de este capitulo. 

10. Ponga objetos de la clase Hern definidos en el ejercicio 6 en un Stash. Apunte 
a ellos e imprlmalos (si no lo ha hecho aun necesitara una funcion Hen : : pri¬ 
nt ()). 

11. Copie los ficheros de implementacion y la prueba de Stack del capitulo 4 y 
compile y pruebe el Stack2.hde este capitulo. 

12. Ponga objetos de la clase Hen del ejercicio 6 dentro de Stack. Apunte a ellos e 
imprlmalos (si no lo ha hecho aun, necesitara ahadir un Hen : : print ()). 

13. Modifique Chesire en Handle . cpp, y verifique que su entorno de desarrollo 
recompila y reemplaza solo este fichero, pero no recompila UseHandle. cpp. 

14. Cree una clase StackOf Int (una pila que guarda enteros) usando la tecnica 
«Gato de Chesire» que esconda la estructura de datos de bajo nivel que usa 
para guardar los elementos, en una clase llamada Stacklmp. Implemente dos 
versiones de Stacklmp: una que use un array de longitud fija de enteros, y 
otra que use un vector<int>. Ponga un tamano maximo para la pila prees- 
tablecido, as! no se tendra que preocupar de expandir el array en la primera 
version. Fljese que la clase StackOf Int. h no tiene que cambiar con Stack- 
Imp. 
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El capitulo 4 constituye una mejora significativa en el uso de li- 
brerfas tomando los diversos componentes de una librerfa C tfpica y 
encapsulandolos en una estructura (un tipo abstracto de dato, llama- 
do clase a partir de ahora). 


Esto no solo permite disponer de un unico punto de entrada en un componente 
de librerfa, tambien oculta los nombres de las funciones con el nombre de la clase. 
Esto le da al disenador de la clase la posibilidad de establecer lfmites claros que 
determinan que cosas puede hacer el programador cliente y que queda fuera de sus 
lfmites. Eso significa que los mecanismos internos de las operaciones sobre los tipos 
de datos estan bajo el control y la discrecion del disenador de la clase, y deja claro a 
que miembros puede y debe prestar atencion el programador cliente. 

Juntos, la encapsulacion y el control de acceso representan un paso significativo 
para aumentar la sencillez de uso de las librerfas. El concepto de «nuevo tipo de 
dato» que ofrecen es mejor en algunos sentidos que los tipos de datos que incorpora 
C. El compilador C++ ahora puede ofrecer garantfas de comprobacion de tipos para 
esos tipos de datos y asf asegura un nivel de seguridad cuando se usan esos tipos de 
datos. 

A parte de la seguridad, el compilador puede hacer mucho mas por nosotros de 
lo que ofrece C. En este y en proximos capftulos vera posibilidades adicionales que 
se han incluido en C++ y que hacen que los errores en sus programas casi salten 
del programa y le agarren, a veces antes incluso de compilar el programa, pero nor- 
malmente en forma de advertencias y errores en el proceso de compilacion. Por este 
motivo, pronto se acostumbrara a la extraha situacion en que un programa C++ que 
compila, funciona a la primera. 

Dos de esas cuestiones de seguridad son la inicializacion y la limpieza. Gran par¬ 
te de los errores de C se deben a que el programador olvida inicializar o liberar 
una variable. Esto sucede especialmente con las librerfas C, cuando el programador 
cliente no sabe como inicializar una estructura, o incluso si debe hacerlo. (A menudo 
las librerfas no incluyen una funcion de inicializacion, de modo que el programador 
cliente se ve forzado a inicializar la estructura a mano). La limpieza es un problema 
especial porque los programadores C se olvidan de las variables una vez que han 
terminado, de modo que omiten cualquier limpieza que pudiera ser necesaria en 
alguna estructura de la librerfa. 

En C++, el concepto de inicializacion y limpieza es esencial para facilitar el uso 
de las librerfas y eliminar muchos de los errores sutiles que ocurren cuando el pro¬ 
gramador cliente olvida cumplir con sus actividades. Este capitulo examina las posi¬ 
bilidades de C++ que ayudan a garantizar una inicializacion y limpieza apropiadas. 
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6.1. Inicializacion garantizada por el constructor 

Tanto la clase Stash como la Stack definidas previamente tienen una funcion 
llamada initialize (). que como indica su nombre se deberia llamar antes de 
usar el objeto. Desafortunadamente, esto significa que el programador cliente debe 
asegurar una inicializacion apropiada. Los programadores cliente son propensos a 
olvidar detalles como la inicializacion cuando tienen prisa por hacer que la libreria 
resuelva sus problemas. En C++, la inicializacion en demasiado importante como 
para dejarsela al programador cliente. El disenador de la clase puede garantizar la 
inicializacion de cada objeto facilitando una funcion especial llamada constructor. Si 
una clase tiene un constructor, el compilador hara que se llame automaticamente al 
constructor en el momenta de la creacion del objeto, antes de que el programador 
cliente pueda llegar a tocar el objeto. La invocacion del constructor no es una opcion 
para el programador cliente; es realizada por el compilador en el punto en el que se 
define el objeto. 

El siguiente reto es como llamar a esta funcion. Hay dos cuestiones. La primera 
es que no deberia ser ningun nombre que pueda querer usar para un miembro de 
la clase. La segunda es que dado que el compilador es el responsable de la invo¬ 
cacion del constructor, siempre debe saber que funcion llamar. La solucion elegida 
por Stroustrup parece ser la mas sencilla y logica: el nombre del constructor es el 
mismo que el de la clase. Eso hace que tenga sentido que esa funcion sea invocada 
automaticamente en la inicializacion. 

Aqui se muestra un clase sencilla con un constructor: 

class X { 
int i; 
public: 

X(); // Constructor 

} ; 


Ahora, se define un objeto, 

void f() { 

X a; 

// ... 

} 


Lo mismo pasa si a fuese un entero: se pide alojamiento para el objeto. Pero cuan¬ 
do el programa llega al punto de ejecucion en el que se define a, se invoca el cons¬ 
tructor automaticamente. Es decir, el compilador inserta la llamada a X : : X () para el 
objeto a en el punto de la definicion. Como cualquier metodo, el primer argumento 
(secreto) para el constructor es el puntero this - la direccion del objeto al que corres- 
ponde ese metodo. En el caso del constructor, sin embargo, this apunta a un bloque 
de memoria no inicializado, y el trabajo del constructor es inicializar esa memoria de 
forma adecuada. 

Como cualquier funcion, el constructor puede tomar argumentos que permitan 
especificar como ha de crearse el objeto, dados unos valores de inicializacion. Los 
argumentos del constructor son una especie de garantia de que todas las partes del 
objeto se inicializan con valores apropiados. Por ejemplo, si una clase Tree 1 tiene 
un constructor que toma como argumento un unico entero que indica la altura del 

1 arbol 
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arbol, entonces debe crear un objeto arbol como este: 

Tree t (12) // arbol de 12 metros 

Si Tree (int) es el unico constructor, el compilador no le permitira crear un 
objeto de otro modo. (En el proximo capltulo veremos como crear multiples cons- 
tructores y diferentes maneras para invocarlos.) 

Y realmente un constructor no es mas que eso; es una funcion con un nombre es¬ 
pecial que se invoca automaticamente por el compilador para cada objeto en el mo¬ 
menta de su creation. A pesar de su simplicidad, tiene un valor excepcional porque 
evita una gran cantidad de problemas y hace que el codigo sea mas facil de escribir 
y leer. En el fragmento de codigo anterior, por ejemplo, no hay una llamada expllcita 
a ninguna funcion initilize () que, conceptualmente es una funcion separada de 
la definicion. En C++, la definicion e inicializacion son conceptos unificados - no se 
puede tener el uno si el otro. 

Constructor y destructor son tipos de funciones muy inusuales: no tienen valor 
de retorno. Esto es distinto de tener valor de retorno void, que indicarla que la fun¬ 
cion no retorna nada pero teniendo la posibilidad de hacer otra cosa. Constructores 
y destructores no retornan nada y no hay otra posibilidad. El acto de traer un objeto 
al programa, o sacarlo de el es algo especial, como el nacimiento o la muerte, y el 
compilador siempre hace que la funcion se llame a si misma, para asegurarse de que 
ocurre realmente. Si hubiera un valor de retorno, y usted pudiera elegir uno propio, 
el compilador no tendrla forma de saber que hacer con el valor retornado, o el pro- 
gramador cliente tendrla que disponer de una invocation expllcita del constructor o 
destructor, lo que eliminarla la seguridad. 


6.2. Limpieza garantizada por el destructor 

Como un programador C, a menudo pensara sobre lo importante de la inicializa¬ 
cion, pero rara vez piensa en la limpieza. Despues de todo, ^que hay que limpiar de 
un int? Simplemente, olvidarlo. Sin embargo, con las librerlas, «dejarlo pasar» en un 
objeto cuando ya no lo necesita no es seguro. Que ocurre si ese objeto modifica algo 
en el hardware, o escribe algo en pantalla, o tiene asociado espacio en el monticu- 
lo(heap). Si simplemente pasa de el, su objeto nunca lograra salir de este mundo. En 
C++, la limpieza es tan importante como la inicializacion y por eso esta garantizada 
por el destructor. 

La sintaxis del destructor es similar a la del constructor: se usa el nombre de 
la clase como nombre para la funcion. Sin embargo, el destructor se distingue del 
constructor porque va precedido de una virgulilla (~). Ademas, el destructor nunca 
tiene argumentos porque la destruction nunca necesita ninguna option. Aqui hay 
una declaration de un destructor: 

class Y { 
public: 

~Y () ; 

} ; 


El destructor se invoca automaticamente por el compilador cuando el objeto sale 
del ambito. Puede ver donde se invoca al constructor por el punto de la definicion 
del objeto, pero la unica evidencia de que el destructor fue invocado es la Have de 
cierre del ambito al que pertenece el objeto. El constructor se invoca incluso aunque 
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utilice goto para saltar fuera del del ambito (goto sigue existiendo en C++ por 
compatibilidad con C.) Deberia notar que un goto no-local, implementado con las 
funciones set jmp y long jmp ( ) de la libreria estandar de C, evitan que el destructor 
sea invocado. (Eso es la especificacion, incluso si su compilador no lo implementa de 
esa manera. Confiar un una caracteristica que no esta en la especificacion significa 
que su codigo no sera portable). 

A continuacion, un ejemplo que demuestra las caracteristicas de constructores y 
destructores que se han mostrado hasta el momenta. 

//: CO6:Constructor!.cpp 
// Constructors & destructors 
#include <iostream> 

using namespace std; 

class Tree { 
int height; 

public: 

Tree (int initialHeight); // Constructor 

-Tree(); // Destructor 

void grow (int years); 
void printsize(); 

} ; 


Tree::Tree (int initialHeight) { 
height = initialHeight; 

) 


Tree::-Tree() { 

cout << "inside Tree destructor" << endl; 
printsize(); 

) 


void Tree::grow (int years) { 
height += years; 

} 


void Tree::printsize() { 

cout << "Tree height is " << height << endl; 

} 


int main () { 

cout << "before opening brace" << endl; 

{ 

Tree t(12); 

cout << "after Tree creation" << endl; 
t.printsize(); 
t.grow (4); 

cout << "before closing brace" << endl; 

} 

cout << "after closing brace" << endl; 

} ///:- 


Y esta seria la salida del programa anterior: 


antes de la Have de aperturae 
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despus de la ocreacin de Tree 
la altura del arbol es 12 
antes de la Have de cierre 
dentro del destructor de Tree 
la altura del arbol es 16e 
despus de la Have de cierre 


Puede ver que el destructor se llama automaticamente al acabar el ambito (Have 
de cierre) en el que esta definido el objeto. 


6.3. Eliminacion del bloque de definiciones 

En C, siempre se definen todas las variables al principio de cada bloque, justo 
despues de la Have de apertura. Ese es un requisito habitual en los lenguajes de pro- 
gramacion, y la razon que se da a menudo es que se considera «buenas practicas de 
programacion». En este tema, yo tengo mis sospechas. Eso siempre me parecio un 
inconveniente, como programador, volver al principio del bloque cada vez que ne- 
cesitaba definir una nueva variable. Tambien encuentro mas legible el codigo cuando 
la definicion de la variable esta certa del punto donde se usa. 

Quiza esos argumentos son estilisticos. En C++, sin embargo, existe un problema 
significativo si se fuerza a definir todos los objetos al comienzo un ambito. Si existe 
un constructor, debe invocarse cuando el objeto se crea. Sin embargo, si el construc¬ 
tor toma uno o mas argumentos, ^como saber que se dispone de la informacion de 
inicializacion al comienzo del ambito? Generalmente no se dispone de esa informa¬ 
cion. Dado que C no tiene el concepto de privado, la separacion entre definicion 
e inicializacion no es un problema. Ademas, C++ garantiza que cuando se crea un 
objeto, es inicializado simultaneamente. Esto asegura que no se tendran objetos no 
inicializados ejecutandose en el sistema. C no tiene cuidado, de hecho, C promueve 
esta practica ya que obliga a que se definan las variables al comienzo de un bloque, 
antes de disponer de la informacion de inicializacion necesaria 2 . 

En general, C++ no permite crear un objeto antes de tener la informacion de ini¬ 
cializacion para el constructor. Por eso, el lenguaje no seria factible si tuviera que 
definir variables al comienzo de un bloque. De hecho, el estilo del lenguaje parece 
promover la definicion de un objeto tan cerca como sea posible del punto en el que 
se usa. En C++, cualquier regia que se aplica a un «objeto» automaticamente tambien 
se refiere a un objeto de un tipo basico. Esto significa que cualquier clase de objeto o 
variable de un tipo basico tambien se puede definir en cualquier punto del bloque. 
Eso tambien significa que puede esperar hasta disponer de la informacion para una 
variable antes de definirla, de modo que siempre puede definir e inicializar al mismo 
tiempo: 

//: CO6:Definelnitialize.cpp 
// Defining variables anywhere 

#include /require.h" 

#include <iostream> 

#include <string> 
using namespace std; 

class G { 

int i; 
public: 

G(int ii); 

2 C99, la version actual del Estandar de C, permite definir variables en cualquier punto del bloque, 
como C++ 
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G::G(int ii) { i = ii; } 
int main() { 

cout << "initialization value? " 

int retval = 0; 

cin >> retval; 

require(retval != 0); 

int y = retval + 3; 

G g (y) ; 

} ///:- 


Puede ver que se ejecuta parte del codigo, entonces se define >retval, que se 
usa para capturar datos de la consola, y entonces se definen y y g. C, al contrario, no 
permite definir una variable en ningun sitio que no sea el comienzo de un bloque. 

En general, deberia definir las variables tan cerca como sea posible del punto en 
que se usa, e inicializarlas siempre cuando se definen. (Esta es una sugerencia de 
estilo para tipos basicos, en los que la inicializacion es opcional.) Es una cuestion de 
seguridad. Reduciendo la duracion de disponibilidad al bloque, se reduce la posibi- 
lidad de que sea usada inapropiadamente en otra parte del bloque. En resumen, la 
legibilidad mejora porque el lector no teiene que volver al inicio del bloque para ver 
el tipo de una variable. 


6.3.1. Bucles for 

En C++, a menudo vera bucles for con el contador definido dentro de la propia 
expresion. 


for 

(int 

j = 

0; 

j < 100; 

j++) { 

\ 

cout 

<< 

"j : 

= " « j 

<< endl; 

s 

for 

(int 

i = 

0; 

i < 100; 

i++) 


cout 

<< 

"i 

= " << i 

<< endl; 


Las sentencias anteriores son casos especiales importantes, que provocan confu¬ 
sion en los programadores novatos de C++. 

Las variables i y j estan definidas directamente dentro la expresion for (algo 
que no se puede hacer en C). Esas variables estan disponibles para usarlas en el 
bucle. Es una sintaxis muy conveniente porque el contexto disipa cualquier duda 
sobre el proposito de i y j, asi que no necesita utilizar nombres extranos como co- 
ntador_bucle_i para quede mas claro. 

Sin embargo, podria resultar confuso si espera que la vida de las variables i y j 
continue despues del bucle - algo que no ocurre' 

El capitulo 3 indica que las sentencias while y switch tambien permiten la defi- 
nicion de objetos en sus expresiones de control, aunque ese uso es menos importante 
que con el bucle for. 

3 Un reciente borrador del estandar C++ dice que la vida de la variable se extiende hasta el final del 
ambito que encierra el bucle for. Algunos compiladores lo implementan, pero eso no es correcto de modo 
que su codigo solo sera portable si limita el ambito al bucle for. 
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Hay que tener cuidado con las variables locales que ocultan las variables del 
ambito superior. En general, usar el mismo nombre para una variable anidada y 
una variable que es global en ese ambito es confuso y propenso a errores 4 

Creo que los bloques pequenos son un indicador de un buen diseno. Si una sola 
funcion requiere varias paginas, quiza esta intentando demasiadas cosas en esa fun- 
cion. Funciones de granularidad mas fina no solo son mas utiles, tambien facilitan la 
localization de errores. 


6.3.2. Alojamiento de memoria 

Ahora una variable se puede definir en cualquier parte del bloque, podrla pare- 
cer que el alojamiento para una variable no se puede llevar a cabo hasta el momento 
en que se define. En realidad, lo mas probable es que el compilador siga la practica 
de pedir todo el alojamiento para el bloque en la Have de apertura del bloque. No 
importa porque, como programador, no puede acceder al espacio asociado (es decir, 
el objeto) hasta que ha sido definido 5 . Aunque el espacio se pi da al comienzo del 
bloque, la llamada al constructor no ocurre hasta el punto en el que se define el ob¬ 
jeto ya que el identificador no esta disponible hasta entonces. El compilador incluso 
comprueba que no ponga la definition del objeto (y por tanto la llamada al construc¬ 
tor) en un punto que dependa de una sentencia conditional, como en una sentencia 
switch o algun lugar que pueda saltar un goto. Descomentar las sentencias del 
siguiente codigo generara un error o aviso. 

//: CO6:Nojump.cpp 

// Can't jump past constructors 

class X { 
public: 

X () ; 

} ; 


X::X() {} 


void f (int i) { 

if (i < 10) { 

//! goto jumpl; // Error: goto bypasses init 


X xl; // Constructor called here 

j ump1: 

switch (i) { 

case 1 : 

X x2; // Constructor called here 


//! 


break; 

case 2 

X x3 ; 

break; 


: // Error: case bypasses init 
// Constructor called here 


int main () { 

f (9) ; 
f(11); 


4 El lenguaje Java considera esto una idea tan mala que lo considera un error. 

5 De acuerdo, probablemente podrla trucarlo usando punteros, pero serla muy, muy malo 
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}///:- 


En el codigo anterior, tanto el goto como el switch pueden saltar la sentencia 
en la que se invoca un constructor. Ese objeto corresponde al ambito incluso si no 
se invoca el constructor, de modo que el compilador dara un mensaje de error. Esto 
garantiza de nuevo que un objeto no se puede crear si no se inicializa. 

Todo el espacio de almacenamiento necesario se asigna en la pila, por supuesto. 
Ese espacio lo faciliza el compilador moviendo el puntero de pila «hacia abajo» (de- 
pendiendo de la maquina implica incrementar o decrementar el valor del puntero de 
pila). Los objetos tambien se pueden alojar en el monticulo usando new, algo que se 
vera en el capitulo 13. (FIXME:Ref C13) 


6.4. Stash con constructores y destructores 

Los ejemplos de los capitulos anteriores tienen funciones que tienen correspon- 
dencia directa con constructores y destructores: initialize () y cleanup (). Este 
es el fichero de cabecera de Stash, utilizando constructor y destructor: 

// : CO6:Stash2.h 

// With constructors & destructors 

#ifndef STASH2_H 
#define STASH2_H 

class Stash { 

int size; // Size of each space 

int quantity; // Number of storage spaces 
int next; // Next empty space 

// Dynamically allocated array of bytes: 

unsigned char* storage; 
void inflate (int increase); 

public: 

Stash (int size); 

-Stash(); 

int add (void* element); 
void* fetch (int index); 
int count (); 

} ; 

#endif // STASH2_H ///:- 


Las unicas definiciones de metodos quehancambiado son initialize () yc- 
leanup (), que han sido reemplazadas con un constructor y un destructor. 

//: CO6:Stash2.cpp {0} 

// Constructors & destructors 

#include "Stash2.h" 

#include /require.h" 

#include <iostream> 

#include <cassert> 
using namespace std; 
const int increment = 100; 


Stash::Stash (int sz) { 



© 


© 


© 
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size = s z; 
quantity = 0; 
storage = 0; 
next = 0; 


int Stash::add (void* element) { 

if (next >= quantity) // Enough space left? 

inflate(increment); 

// Copy element into storage, 

// starting at next empty space: 
int startBytes = next * size; 
unsigned char* e = (unsigned char* )element; 
for(int i = 0; i < size; i++) 

storage[startBytes + i] = e [i]; 
next++; 

return (next - 1); // Index number 


void* Stash::fetch (int index) { 

require(0 <= index, "Stash::fetch (-)index"); 
if (index >= next) 

return 0; //To indicate the end 
// Produce pointer to desired element: 
return &(storage[index * size]); 


int Stash::count () { 

return next; // Number of elements in CStash 

} 


void Stash::inflate (int increase) { 
require(increase > 0, 

"Stash::inflate zero or negative increase"); 
int newQuantity = quantity + increase; 
int newBytes = newQuantity * size; 
int oldBytes = quantity * size; 

unsigned char* b = new unsigned char [newBytes]; 
for(int i = 0; i < oldBytes; i++) 

b[i] = storage[i]; // Copy old to new 
delete [] (storage); // Old storage 
storage = b; // Point to new memory 
quantity = newQuantity; 


Stash::-Stash() { 

if (storage != 0) { 

cout << "freeing storage" << endl; 
delete []storage; 


} ///:- 


Puede ver que las funciones de require . h se usan para vigilar errores del pro- 
grama dor, en lugar de assert (). La salida de un assert () fallido no es tan util 
como las funciones de require . h (que se veran mas adelante en el libro). 
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Dado que inflate () es privado, el unico modo en que require () podria fa- 
llar seria si uno de los otros miembros pasara accidentalmente un valor incorrecto a 
inf late (). Si esta seguro de que eso no puede pasar, deberia considerar eliminar 
el require (), pero deberia tener en mente que hasta que la clase sea estable, siem- 
pre existe la posibilidad de que el codigo nuevo anadido a la clase podria provocar 
errores. El coste de require () es bajo (y podria ser eliminado automaticamentepor 
el preprocesador) mientras que la robustez del codigo es alta. 

Fijese como en el siguiente programa de prueba la definicion de los objetos St¬ 
ash aparece justo antes de necesitarse, y como la inicializacion aparece como parte 
de la definicion, en la lista de argumentos del constructor. 

//: CO6:Stash2Test.cpp 
//{L} Stash2 

// Constructors & destructors 

#include "Stash2.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

int main () { 

Stash intStash (sizeof(int) ); 
for(int i = 0; i<100; i++) 
intStash.add(&i); 

for(int j = 0; j < intStash.count (); j++) 
cout << "intStash.fetch(" << j << ") = " 

<< * (int* )intStash.fetch ( j) 

<< endl; 

const int bufsize = 80; 

Stash stringStash (sizeof(char) * bufsize); 
ifstream in("Stash2Test.cpp"); 
assure(in, " Stash2Test.cpp"); 
string line; 

while (getline (in, line)) 

stringStash.add( (char* )line.c_str()); 
int k = 0; 

char* cp; 

while((cp = (char*) stringStash.fetch(k++))!=0) 
cout << "stringStash.fetch(" << k << ") = " 

<< cp << endl; 

} ///:~ 


Tambien observe que se han eliminado llamadas a cleanup (), pero los des- 
tructores se llaman automaticamente cuando intStash y stringStash salen del 
ambito. 

Una cosa de la que debe ser consciente en los ejemplos con Stash: Tengo mu- 
cho cuidado usando solo tipos basicos; es decir, aquellos sin destructores. Si intenta 
copiar objetos dentro de Stash, apareceran todo tipo de problemas y no funcionara 
bien. En realidad la Libreria Estandar de C++ puede hacer copias correctas de objetos 
en sus contenedores, pero es un proceso bastante sucio y complicado. En el siguiente 
ejemplo de Stack, vera que se utilizan punteros para esquivar esta cuestion, y en 
un capitulo posterior Stash tambien se convertira para que use punteros. 
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6.5. Stack con constructores y destructores 

Reimplementar la lista enlazada (dentro de Stack) con constructores y destruc¬ 
tores muestra claramente como costructores y destructores utilizan new y delete. 
Este es el fichero de cabecera modficado: 

// : CO6:Stack3.h 

// With constructors/destructors 

#ifndef STACK3_H 
#define STACK3_H 

class Stack { 
struct Link { 
void* data; 

Link* next; 

Link (void* dat, Link* nxt); 

-Link(); 

}* head; 

public: 

Stack(); 

-Stack(); 

void push (void* dat); 
void* peek(); 
void* pop (); 

} ; 

#endif // STACK3_H ///:- 


No solo hace que Stack tenga un constructor y destructor, tambien aparece la 
clase anidada Link. 

//: CO6:Stack3.cpp {0} 

// Constructors/destructors 

#include "Stack3.h" 

#include /require.h" 

using namespace std; 

Stack::Link::Link (void* dat, Link* nxt) { 
data = dat; 
next = nxt; 

} 


Stack::Link::-Link () { } 

Stack::Stack () { head = 0; } 

void Stack::push (void* dat) { 
head = new Link(dat,head); 

} 


void* Stack::peek () { 

require(head != 0, "Stack empty"); 
return head->data; 

1 


void* Stack::pop() { 

if (head == 0) return 0; 
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void* result = head->data; 

Link* oldHead = head; 
head = head->next; 
delete oldHead; 
return result; 

} 

Stack::-Stack () { 

require(head == 0, "Stack not empty"); 

} ///:- 


El constructor Link : Link () simplemente inicializa los punteros data y next, 
asi que en Stack : :push (), la linea: 

head = new Link(dat,head); 

no solo aloja un nuevo enlace (usando creation dinamica de objetos con la sen- 
tencia new, vista en el capitulo 4), tambien inicializa los punteros para ese enlace. 

Puede que le asombre que el destructor de Link no haga nada - en concreto, ^por 
que no elimina el puntero data? Hay dos problemas. En el capitulo 4, en el que apa- 
recio Stack, se decia que no puede eliminar un puntero void si esta apuntado a un 
objeto (una afirmacion que se demostrara en el capitulo 13). Pero ademas, si el des¬ 
tructor de Link eliminara el puntero data, pop ( ) retornaria un puntero a un objeto 
borrado, que definitivamente supone un error. A veces esto se considera como una 
cuestion de propiedad: Link y por consiguiente Stack solo contienen los punteros, 
pero no son responsables de su limpieza. Eso significa que debe tener mucho cui- 
dado para saber quien es el responsable. Por ejemplo, si no invoca pop () y elimina 
todos los punteros de Stack () , no se limpiaran automaticamente por el destructor 
de Stack. Esto puede ser una cuestion engorrosa y llevar a fugas de memoria, de 
modo que saber quien es el responsable de la limpieza de un objeto puede suponer 
la diferencia entre un programa correcto y uno erroneo - es decir, porque Stack¬ 
er -Stack () imprime un mensaje de error si el objeto Stack no esta vacio en el 
momenta su destruction. 

Dado que el alojamiento y limpieza de objetos Link esta oculto dentro de Stack 
- es parte de la implementation subyacente - no vera este suceso en el programa de 
prueba, aunque sera el responsable de eliminar los punteros que devuelva pop (): 

//: CO6:Stack3Test.epp 
//{L} Stack3 
//{T} Stack3Test.epp 
// Constructors/destructors 

#include "Stack3.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

int main(int arge, char* argv[]) { 

requireArgs(arge, 1); // File name is argument 
ifstream in(argv[l]); 
assure(in, argvfl]); 

Stack textlines; 


198 
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string line; 

// Read file and store lines in the stack: 
while (getline(in, line)) 

textlines.push (new string(line)); 

// Pop the lines from the stack and print them: 
string* s; 

while((s = (string*)textlines.pop()) != 0) { 

cout << *s << endl; 

delete s; 

} 

} ///:~ 


En este caso, todas las lineas de textlines son desapiladas y eliminadas, pero 
si no fuese asi, obtendria un mensaje de require () que indica que hubo una fuga 
de memoria. 


6.6. Inicializacion de tipos agregados 

Un agregado es justo lo que parece: un grupo de cosas agrupados juntos. Esta 
definicion incluye agregados de tipos mixtos, como estructuras o clases. Un array es 
un agregado de un unico tipo. 

Inicializar agregados puede ser tedioso y propenso a errores. La inicializacion de 
agregados en C++ lo hace mucho mas seguro. Cuando crea un objeto agregado, todo 
lo que tiene que hacer es una asignacion, y la inicializacion la hara el compilador. Esta 
asignacion tiene varias modalidades, dependiendo del tipo de agregado del que se 
trate, pero en cualquier caso los elementos en la asignacion deben estar rodeadas de 
Haves. Para arrays de tipos basicos es bastante simple: 

int a [5] = { 1, 2, 3, 4, 5}; 

Si intenta escribir mas valores que elementos tiene el array, el compilador dara 
un mensaje de error. Pero, ^que ocurre si escribe menos valores? Por ejemplo: 

int b[6] = {0}; 

Aqui, el compilador usara el primer valor para el primer elemento del array, y 
despues usara ceros para todos los elementos para los que no se tiene un valor. Fijese 
en que este comportamiento en la inicializacion no ocurre si define un array sin una 
lista de valores de inicializacion. Asi que la expresion anterior es una forma resumida 
de inicializar a cero un array sin usar un bucle f or, y sin ninguna posibilidad de un 
«error por uno» (Dependiendo del compilador, tambien puede ser mas eficiente que 
un bucle for). 

Un segundo metodo para los arrays es el conteo automatico, en el cual se permite 
que el compilador determine el tamano del array basandose en el numero de valores 
de inicializacion. 

int c | ; = { 1, 2, 3, 4 }; 

Ahora, si decide anadir otro elemento al array, simplemente debe anadir otro va¬ 
lor. Si puede hacer que su codigo necesite modificaciones en un unico sitio, reducira 
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la posibilidad de introducir errores durante la modificacion. Pero, ^como determinar 
el tamano del array? La expresion sizeof c / sizeof *c (el tamano del array 
completo dividido entre el tamano del primer elemento) es un truco que hace que 
no sea necesario cambiarlo si cambia el tamano del array 6 : 

for(int i = 0; i < sizeof c / sizeof *c; i++) 
c[i]++; 


Dado que las estructuras tambien son agregados, se pueden inicializar de un mo- 
do similar. Como en una estructura estilo-C todos sus miembros son publicos, se 
pueden asignar directamente: 

struct X { 
int i; 
float f; 
char c; 

} ; 


X xl = { 1, 2.2, 'c' }; 

Si tiene una array de esos objetos, puede inicializarlos usando un conjunto anida- 
do de llaves para cada elemento: 

X x2[3] = { {1, 1.1, 'a'}, {2, 2.2, 'b'} }; 

Aqul, el tercer objeto se inicializo a cero. 

Si alguno de los atributos es privado (algo que ocurre tlpicamente en el caso de 
clases bien disenadas en C++), o incluso si todos son publicos pero hay un cons¬ 
tructor, las cosas son distintas. En el ejemplo anterior, los valores se han asignado 
directamente a los elementos del agregado, pero los constructores son una manera 
de forzar que la inicializacion ocurra por medio de una interfaz formal. Aqul, los 
constructores deben ser invocados para realizar la inicializacion. De modo, que si 
tiene un constructor parecido a este, 

struct Y { 
float f; 
int i; 

Y(int a); 

} ; 


Debe indicar la llamada al constructor. La mejor aproximacion es una expllcita 
como la siguiente: 

Y y 1 [ ] = { Y (1) , Y (2) , Y (3) }; 

Obtendra tres objetos y tres llamadas al constructor. Siempre que tenga un cons¬ 
tructor, si es una estructura con todos sus miembros publicos o una clase con atri¬ 
butos privados, toda la inicializacion debe ocurrir a traves del constructor, incluso si 
esta usando la inicializacion de agregados. 

6 En el segundo volumen de este libro (disponible libremente en www.BmceEckel.com), vera una 
forma mas corta de calcular el tamano de un array usando plantillas. 
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Se muestra un segundo ejemplo con un constructor con multiples argumentos. 

//: CO6:Multiarg.cpp 
// Multiple constructor arguments 
// with aggregate initialization 
#include <iostream> 

using namespace std; 

class Z { 

int i , j; 

public: 

Z(int ii, int j j); 
void print (); 

} ; 


Z::Z(int ii, int jj) { 
i = i i ; 

j = jj; 

} 


void Z: :print () { 

cout << "i = " << i << ", j = " << j << endl; 

} 


int main() { 

Z zz[| = { Z (1,2) , Z (3, 4) , Z (5, 6) , Z (7, 8) }; 

for(int i = 0; i < sizeof zz / sizeof *zz; i++) 
zz[i].print(); 

} ///:~ 


Frjese en como se invoca un constructor expllcito para cada objeto de un array. 


6.7. Constructores por defecto 

Un constructor por defecto es uno que puede ser invocado sin argumentos. Un 
constructor por defecto se usa para crear un «objeto vainilla» 7 pero tambien es im- 
portante cuando el compilador debe crear un objeto pero no se dan detalles. Por 
ejemplo, si se toma la struct Y definida previamente y se usa en una definicion 
como esta, 

Y y2 [2] = { Y (1) } ; 

el compilador se quejara porque no puede encontrar un constructor por defecto. 
El segundo objeto del array se creara sin argumentos, y es ahl donde el compila¬ 
dor busca un constructor por defecto. De hecho, si simplemente define un array de 
objetos Y, 

Y y 3 [ 7 ] ; 

el compilador se quejara porque deberla haber un constructor para inicializar 
cada objeto del array. 

7 N.de.T: Para los anglosajones Vainilla es el sabor mas «sencillo», sin adornos ni sofisticaciones. 
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El mismo problema ocurre si crea un objeto individual como este: 

Y y4; 


Recuerde, si tiene un constructor, el compilador asegura que siempre ocurrira la 
construction, sin tener en cuenta la situation. 

El constructor por defecto es tan importante que si (y solo si) una estructura (st¬ 
ruct o clase) no tiene constructor, el compilador creara uno automaticamente. Por 
ello, lo siguiente funciona: 

//: CO6:AutoDefaultConstructor.cpp 
// Automatically-generated default constructor 

class V { 

int i; // private 
}; //No constructor 

int main() { 

V v, v2[10]; 

} ///:- 


Si se han definido constructores, pero no hay constructor por defecto, las instan- 
cias anteriores de V provocaran errores durante la compilation. 

Podria pensarse que el constructor sintetizado por el compilador deberia hacer 
alguna inicializacion inteligente, como poner a cero la memoria del objeto. Pero no 
lo hace - anadiria una sobrecarga que quedaria fuera del control del programador. Si 
quiere que la memoria sea inicializada a cero, deberia hacerlo escribiendo un cons¬ 
tructor por defecto explicito. 

Aunque el compilador creara un constructor por defecto, el comportamiento de 
ese constructor raramente hara lo que se espera. Deberia considerar esta caracteris- 
tica como una red de seguridad, pero que debe usarse con moderation. En general, 
deberia definir sus constructores explicitamente y no permitir que el compilador lo 
haga por usted. 


6.8. Resumen 

Los mecanismos aparentemente elaborados proporcionados por C++ deberian 
darle una idea de la importancia critica que tiene en el lenguaje la inicializacion y 
limpieza. Como Stroustrup fue quien diseno C++, una de las primeras observacio- 
nes que hizo sobre la productividad de C fue que una parte importante de los proble- 
mas de programacion se deben a la inicializacion inapropiada de las variables. Este 
tipo de errores son dificiles de encontrar, y otro tanto se puede decir de una limpie¬ 
za inapropiada. Dado que constructores y destructores le permiten garantizar una 
inicializacion y limpieza apropiada (el compilador no permitira que un objeto sea 
creado o destruido sin la invocation del constructor y destructor correspondiente), 
conseguira control y seguridad. 

La inicializacion de agregados esta incluida de un modo similar - previene de 
errores de inicializacion tipicos con agregados de tipos basicos y hace que el codigo 
sea mas corto. 
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La seguridad durante la codificacion es una cuestion importante en C++. La ini¬ 
cializacion y la limpieza son una parte importante, pero tambien vera otras cuestio- 
nes de seguridad mas adelante en este libro. 


6.9. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Escriba una clase simple llama da Simple con un constructor que imprima algo 
indicando que se ha invocado. En main () creae un objeto de esa clase. 

2. Anada un destructor al Ejercicio 1 que imprima un mensaje indicado que se ha 
llamado. 

3. Modifique el Ejercicio 2 de modo que la clase contenga un miembro int. Mo- 
difique el constructor para que tome un argumento int que se almacene en el 
atributo. Tan to el constructor como el destructor deberan imprimir el valor del 
entero como parte se su mensaje, de modo que se pueda ver como se crean y 
destruyen los objetos. 

4. Demuestre que los destructores se invocan incluso cuando se utiliza goto para 
salir de un bucle. 

5. Escriba dos bucles for que impriman los valores de 0 a 10. En el primero, de- 
fina el contador del bucle antes del bucle, y en el segundo, defina el contador 
en la expresion de control del for. En la segunda parte del ejercicio, modifi¬ 
que el identificador del segundo bucle para que tenga el mismo nombre del el 
contador del primero y vea que hace el compilador. 

6. Modifique los ficheros Handle . h. Handle . cpp, y UseHandle . cpp del capi- 
tulo 5 para que usen constructores y destructores. 

7. Use inicializacion de agregados para crear un array de double en el que se indi- 
que el tamano del array pero no se den suficientes elementos. Imprima el array 
usando sizeof para determinar el tamano del array. Ahora cree un array de 
double usando inicializacion de agregados y conteo automatico. Imprima el 
array. 

8. Utilice inicializacion de agregados para crear un array de objetos string. Cree 
una Stack para guardar esas cadenas y recorra el array, apilando cada cadena 
en la pila. Finalmente, extraiga las cadenas de la pila e imprima cada una de 
ellas. 

9. Demuestre el conteo automatico e inicializacion de agregados con un array de 
objetos de la clase creada en el Ejercicio 3. Anada un metodo a la clase que im¬ 
prima un mensaje. Calcule el tamano del array y recorralo, llamando al nuevo 
metodo. 

10. Cree una clase sin ningun constructor, y demuestre que puede crear objetos con 
el constructor por defecto. Ahora cree un constructor explicito (que tenga un 
argumento) para la clase, e intente compilar de nuevo. Explique lo que ocurre. 
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7: Sobrecarga de funciones y argu- 
mentos por defecto 

Una de las caractensticas mas importantes en cualquier lenguaje 
de programacion es la utilizacion adecuada de los nombres. 

Cuando crea un objeto (una variable) le esta asignando un nombre a una region 
de memoria. Una funcion es un nombre para una accion. El hecho de poner nombres 
adecuados a la hora de describir un sistema hace que un programa sea mas facil de 
entender y modificar. Es muy parecido a la prosa escrita, el objetivo es comunicarse 
con los lectores. 

Cuando se trata de representar sutilezas del lenguaje humano en un lenguaje de 
programacion aparecen los problemas. A menudo, la misma palabra expresa diver- 
sos significados dependiendo del contexto. Una palabra tiene multiples significa- 
dos, es decir, esta sobrecarga da (polisemia). Esto es muy util, especialmente cuando 
las diferencias son obvias. Puede decir «lave la camiseta, lave el coche.» Seria es- 
tupido forzar la expresion anterior para convertirla en «lavar_camiseta la camiseta, 
lavar_coche el coche» pues el oyente no tiene que hacer ninguna distincion sobre 
la accion realizada. Los lenguajes humanos son muy redundantes, asi que incluso 
si pierde algunas palabras, todavia puede determinar el significado. Los identifica- 
dores unicos no son necesarios, pues se puede deducir el significado a partir del 
contexto. 

Sin embargo, la mayoria de los lenguajes de programacion requieren que se uti- 
lice un identificador unico para cada funcion. Si tiene tres tipos diferentes de datos 
que desee imprimir en la salida: inf, char y float, generalmente tiene que crear tres 
funciones diferentes, como por ejemplo print_int (), print_char () y print- 
_f loat (). Esto constituye un trabajo extra tanto para el programador, al escribir el 
programa, como para el lector que trate de entenderlo. 

En C++ hay otro factor que fuerza la sobrecarga de los nombres de funcion: el 
constructor. Como el nombre del constructor esta predeterminado por el nombre 
de la clase, podria parecer que solo puede haber un constructor. Pero, ^que ocurre 
si desea crear un objeto de diferentes maneras? Por ejemplo, suponga que escribe 
una clase que puede inicializarse de una manera estandar o leyendo informacion de 
un fichero. Necesita dos constructores, uno que no tiene argumentos (el constructor 
por defecto) y otro que tiene un argumento de tipo string, que es el nombre del 
fichero que inicializa el objeto. Ambos son constructores, asi pues deben tener el 
mismo nombre: el nombre de la clase. Asi, la sobrecarga de funciones es esencial 
para permitir el mismo nombre de funcion (el constructor en este caso) se utilice con 
diferentes argumentos. 

Aunque la sobrecarga de funciones es algo imprescindible para los constructo- 
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res, es tambien de utilidad general para cualquier funcion, incluso aquellas que no 
son metodos. Ademas, la sobrecarga de funciones significa que si tiene dos librerias 
que contienen funciones con el mismo nombre, no entraran en conflicto siempre y 
cuando las listas de argumentos sean diferentes. A lo largo del capitulo se mostraran 
todos los detalles. 

El tema de este capitulo es la eleccion adecuada de los nombres de la funciones. 
La sobrecarga de funciones permite utilizar el mismo nombre para funciones dife¬ 
rentes, pero hay otra forma mas adecuada de llamar a una funcion. ^Que ocurrirla 
si le gustara llamar a la misma funcion de formas diferentes? Cuando las funciones 
tienen una larga lista de argumentos, puede resultar tediosa la escritura (y confusa 
la lectura) de las llamadas a la funcion cuando la mayoria de los argumentos son lo 
mismos para todas las llamadas. Una caracterlstica de C++ comunmente utilizada 
se llama argumento por defecto. Un argumento por defecto es aquel que el compilador 
inserta en caso de que no se especifique cuando se llama a la funcion. Asi, las lla¬ 
madas f ( "hello" ), f ( "hi " , 1) yf ("howdy", 2, ' c') pueden ser llamadas 
a la misma funcion. Tambien podrian ser llamadas a tres funciones sobrecargadas, 
pero cuando las listas de argumentos son tan similares, querra que tengan un com- 
portamiento similar, que le lleva a tener una unica funcion. 

La sobrecarga de funciones y los argumentos por defecto no son muy complica- 
dos. En el momento en que termine este capitulo, sabra cuando utilizarlos y enten- 
dera los mecanismos infernos que el compilador utiliza en tiempo de compilacion y 
enlace. 


7.1. Mas decoracion de nombres 

En el Capitulo 4 se presento el concepto de decoracion de nombres. En el codigo: 


void f(); 

class X { void f(); }; 


La funcion f () dentro del ambito de la clase X no entra en conflicto con la version 
global de f (). El compilador resuelve los ambitos generando diferentes nombres 
infernos tanto para la version global de f ( ) como para X: : f (). En el Capitulo 4 se 
sugirio que los nombres son simplemente el nombre de la clase junto con el nombre 
de la funcion. Un ejemplo podria ser que el compilador utilizara como nombres _f y 
_X_f . Sin embargo ahora se ve que la decoracion del nombre de la funcion involucra 
algo mas que el nombre de la clase. 

He aqui el porque. Suponga que quiere sobrecargar dos funciones 

void print(char); 
void print(float); 


No importa si son globales o estan dentro de una clase. El compilador no pue¬ 
de generar identificadores infernos unicos si solo utiliza el ambito de las funciones. 
Terminaria con _print en ambos casos. La idea de una funcion sobrecargada es 
que se utilice el mismo nombre de funcion, pero diferente lista de argumentos. Asi 
pues, para que la sobrecarga funcione el compilador ha de decorar el nombre de la 
funcion con los nombres de los tipos de los argumentos. Las funciones planteadas 
mas arriba, definidas como globales, producen nombres infernos que podrian pare- 
cerse a algo asi como _print_char y _print_f loat. Notese que como no hay 
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ningun estandar de decoracion, podra obtener resultados diferentes de un compi- 
lador a otro. (Puede ver lo que saldria diciendole al compilador que genere codigo 
fuente en ensamblador). Esto, por supuesto, causa problemas si desea comprar unas 
librerias compiladas por un compilador y enlazador particulares, aunque si la deco¬ 
racion de nombres fuera estandar, habria otros obstaculos debido a las diferencias de 
generation de codigo maquina entre compiladores. 

Esto es todo lo que hay para la sobrecarga de funciones: puede utilizar el mismo 
nombre de funcion siempre y cuando la lista de argumentos sea diferente. El compi¬ 
lador utiliza el nombre, el ambito y la lista de argumentos para generar un nombre 
interno que el enlazador pueda utilizar. 


7.1.1. Sobrecarga en el valor de retorno 

Es muy comun la pregunta «^Por que solamente el ambito y la lista de argumen¬ 
tos? ^Por que no tambien el valor de retorno?». A primera vista parece que tendria 
sentido utilizar tambien el valor de retorno para la decoracion del nombre interno. 
De esta manera, tambien podria sobrecargar con los valores de retorno: 

void f(); 
int f(); 

Esto funciona bien cuando el compilador puede determinar sin ambigiiedades a 
que tipo de valor de retorno se refiere, como en int x = f () ;. No obstante, en C 
se puede llamar a una funcion y hacer caso omiso del valor de retorno (esto es, puede 
querer llamar a la funcion debido a sus efectos laterales). ^Como puede el compilador 
distinguir a que funcion se refiere en este caso? Peor es la dificultad que tiene el lector 
del codigo fuente para dilucidar a que funcion se refiere. La sobrecarga mediante el 
valor de retorno solamente es demasiado sutil, por lo que C++ no lo permite. 


7.1.2. Enlace con FIXME:tipos seguros 

Existe un beneficio anadido a la decoracion de nombres. En C hay un problema 
particularmente fastidioso cuando un programador cliente declara mal una funcion 
o, aun peor, se llama a una funcion sin haber sido previamente declarada, y el compi¬ 
lador inhere la declaration de la funcion mediante la forma en que se llama. Algunas 
veces la declaration de la funcion es correcta, pero cuando no lo es, suele resultar en 
un fallo dificil de encontrar. 

A causa de que en C++ se deben declarar todas las funciones antes de llamarlas, 
las probabilidades de que ocurra lo anteriormente expuesto se reducen drasticamen- 
te. El compilador de C++ rechaza declarar una funcion automaticamente, asi que es 
probable que tenga que incluir la cabecera apropiada. Sin embargo, si por alguna 
razon se las apana para declarar mal una funcion, o declararla a mano o incluir una 
cabecera incorrecta (quiza una que sea antigua), la decoracion de nombres propor- 
ciona una seguridad que a menudo se denomina como enlace con tipos seguros. 

Considere el siguiente escenario. En un fichero esta la definition de una funcion: 

//: C07:Def.cpp {0} 

// Function definition 

void f(int) {} 

III:- 
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En el segundo fichero, la funcion esta mal declarada y en main se le llama: 

//: C07:Use.cpp 
//{L} Def 

// Function misdeclaration 

void f (char); 

int main () { 

//! f(l); // Causes a linker error 

} ///:- 


Incluso aunque pueda ver que la funcion es realmente f (int) , el compilador 
no lo sabe porque se le dijo, a traves de una declaration expllcita, que la funcion es 
f (char) . As! pues, la compilation tiene exito. En C, el enlazador podria tener tam- 
bien exito, pero no en C++. Como el compilador decora los nombres, la definition se 
convierte en algo as! como f_int, mientras que se trata de utilizar f_char. Cuando 
el enlazador intenta resolver la referenda a f_char, solo puede encontrar f_int, 
y da un mensaje de error. Este es el enlace de tipos seguro. Aunque el problema no 
ocurre muy a menudo, cuando ocurre puede ser increfblemente dificil de encontrar, 
especialmente en proyectos grandes. Este metodo puede utilizarse para encontrar 
un error en C simplemente intentando compilarlo en C++. 

7.2. Ejemplo de sobrecarga 

Ahora puede modificar ejemplos anteriores para utilizar la sobrecarga de funcio¬ 
nes. Como ya se dijo, el lugar inmediatamente mas util para la sobrecarga es en los 
constructores. Puede comprobarlo en la siguiente version de la clase Stash: 

// : C07:Stash3.h 
// Function overloading 

#ifndef STASH3_H 
#define STASH3_H 

class Stash { 

int size; // Size of each space 

int quantity; // Number of storage spaces 
int next; // Next empty space 

// Dynamically allocated array of bytes: 

unsigned char* storage; 
void inflate (int increase); 

public: 

Stash (int size); // Zero quantity 
Stash (int size, int initQuantity); 

-Stash(); 

int add (void* element); 
void* fetch (int index); 
int count (); 

} ; 

#endif // STASH3_H ///:- 
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El primer constructor de Stash es el mismo que antes, pero el segundo tiene 
un argumento Quantity que indica el numero inicial de espacios de memoria que 
podran ser asignados. En la definicion, puede observar que el valor interno de qua¬ 
ntity sepone a cero, al igual que el puntero storage. En el segundo constructor, la 
llamada a inflate (initQuantity ) incrementa quantity al tamano asignado: 

//: C07:Stash3.cpp {0} 

// Function overloading 

#include "Stash3.h" 

#include "../require.h" 

#include <iostream> 

#include <cassert> 
using namespace std; 
const int increment = 100; 

Stash::Stash (int sz) { 
size = sz; 
quantity = 0; 
next = 0; 
storage = 0; 

} 

Stash::Stash (int sz, int initQuantity) { 
size = sz; 
quantity = 0; 
next = 0; 
storage = 0; 
inflate(initQuantity) ; 

} 


Stash::-Stash() { 

if (storage != 0) { 

cout << "freeing storage" << endl; 
delete []storage; 



int Stash::add (void* element) { 

if (next >= quantity) // Enough space left? 

inflate(increment); 

// Copy element into storage, 

// starting at next empty space: 
int startBytes = next * size; 
unsigned char* e = (unsigned char* )element; 
for(int i = 0; i < size; i++) 

storage[startBytes + i] = e[i]; 
next++; 

return (next - 1); // Index number 


void* Stash::fetch (int index) { 

require(0 <= index, "Stash::fetch (-)index"); 
if (index >= next) 

return 0; //To indicate the end 
// Produce pointer to desired element: 
return &(storage[index * size]); 
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int Stash::count() { 

return next; // Number of elements in CStash 

} 


void Stash::inflate (int increase) { 
assert(increase >= 0); 
if (increase == 0) return; 
int newQuantity = quantity + increase; 
int newBytes = newQuantity * size; 
int oldBytes = quantity * size; 

unsigned char* b = new unsigned char [newBytes]; 
for(int i = 0; i < oldBytes; i++) 

b [i] = storage [i] ; // Copy old to new 
delete [](storage); // Release old storage 
storage = b; // Point to new memory 
quantity = newQuantity; // Adjust the size 

} //ft- 


Cuando utiliza el primer constructor no se asigna memoria alguna para stora¬ 
ge. La asignacion ocurre la primera vez que trata de ana dir (con add ()) un objeto y 
en cualquier momenta en el que el bloque de memoria actual se exceda en add (). 

Ambos constructores se prueban en este programa de ejemplo: 

//: C07:Stash3Test.cpp 
//{L} Stash3 
// Function overloading 

#include "Stash3.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

int main() { 

Stash intStash (sizeof(int) ); 
for(int i=0; i<100; i++) 
intStash.add(&i); 

for(int j = 0; j < intStash.count (); j++) 
cout << "intStash.fetch (" << j << ") = " 

<< * (int* )intStash.fetch ( j) 

<< endl; 

const int bufsize = 80; 

Stash stringStash (sizeof(char) * bufsize, 100); 
ifstream in("Stash3Test.cpp"); 
assure(in, "Stash3Test.cpp"); 
string line; 

while (getline(in, line)) 

stringStash.add( (char* )line.c_str()); 
int k = 0; 

char* cp; 

while((cp = (char*) stringStash.fetch(k++))!=0) 
cout << "stringStash.fetch(" << k << ") = " 

<< cp << endl; 

} ///'.- 
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La llamada al constructor para la variable stringStash utiliza un segundo ar- 
gumento; se presume que conoce algo especial sobre el problema especifico que us- 
ted esta resolviendo que le permite elegir un tamano inicial para el Stash. 


7.3. Uniones 

Como ya ha visto, la unica diferencia en C++ entre struct y class es que st¬ 
ruct pone todo por defecto a public y la clase pone todo por defecto a private. 
Una struct tambien puede tener constructores y destructores, como cabia esperar. 
Pero resulta que el tipo union tambien puede tener constructores, destructores, me- 
todos e incluso controles de acceso. Puede ver de nuevo la utilizacion y las ventajas 
de la sobrecarga de funciones en el siguiente ejemplo: 

//: C07:UnionClass.cpp 

// Unions with constructors and member functions 

#include<iostream> 

using namespace std; 

union U { 

private: // Access control too! 

int i; 
float f; 
public: 

U (int a); 

U (float b); 

~U () ; 

int read_int(); 
float read_float(); 

} ; 


U: :U (int a) { i = a; } 

U::U (float b) { f = b; } 

U::~U() | cout << "U::~U()\n"; } 

int U::read_int() { return i; } 

float U::read_float() { return f; } 

int main () { 

U X(12) , Y(1.9F); 

cout << X.read_int() << endl; 

cout << Y.read_float() << endl; 

} ///:- 


Podria pensar que en el codigo anterior la unica diferencia entre una union y una 
clase es la forma en que los datos se almacenan en memoria (es decir, el int y el 
float estan superpuestos). Sin embargo una union no se puede utilizar como clase 
base durante la herencia, lo cual limita bastante desde el punto de vista del diseno 
orientado a objetos (veremos la herencia en el Capitulo 14). 

Aunque los metodos civilizan ligeramente el tratamiento de uniones, sigue sin 
haber manera alguna de prevenir que el programador cliente seleccione el tipo de 
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elemento equivocado una vez que la union se ha inicializado. En el ejemplo ante¬ 
rior, podrla escribir X. read_f loat () incluso aunque sea inapropiado. Sin embar¬ 
go, una union «segura» se puede encapsular en una clase. En el siguiente ejemplo, 
vea como la enumeracion clarifica el codigo, y como la sobrecarga viene como anillo 
al dedo con los constructores: 

//: C07:SuperVar.cpp 
// A super-variable 

#include <iostream> 

using namespace std; 

class SuperVar { 
enum { 

character, 
integer, 
floating_point 
} vartype; // Define one 
union { // Anonymous union 

char c; 
int i ; 
float f; 

} ; 

public: 

SuperVar (char ch); 

SuperVar (int ii) ; 

SuperVar (float ff) ; 
void print (); 

} ; 


SuperVar::SuperVar (char ch) { 
vartype = character; 
c = ch; 

} 


SuperVar::SuperVar (int ii) { 
vartype = integer; 
i = ii; 

} 


SuperVar::SuperVar (float ff) { 
vartype = floating_point; 
f = ff; 

} 


void SuperVar::print () { 

switch (vartype) { 
case character: 

cout << "character: " << c << endl; 

break; 

case integer: 

cout << "integer: " << i << endl; 

break; 

case floating_point: 

cout << "float: " << f << endl; 

break; 

} 
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int main () { 

SuperVar A('c'), B(12), C(1.44F); 

A. print () ; 

B. print () ; 

C. print () ; 

} ///:-• 


En ese ejemplo la enumeracion no tiene nombre de tipo (es una enumeracion 
sin etiqueta). Esto es aceptable si va a definir inmediatamente un ejemplar de la 
enumeracion, tal como se hace aqui. No hay necesidad de indicar el nombre del tipo 
de la enumeracion en el futuro, por lo que aqui el nombre de tipo es opcional. 

La union no tiene nombre de tipo ni nombre de variable. Esto se denomina union 
anonima, y crea espacio para la union pero no requiere acceder a los elementos de 
la union con el nombre de la variable y el operador punto. Por ejemplo, si su union 
anonima es: 

//: C07:AnonymousUnion.cpp 

int main () { 

union { 
int i ; 
float f; 

} ; 

// Access members without using qualifiers: 
i = 12; 
f = 1.22; 

} /// : ~ 


Note que accede a los miembros de una union anonima igual que si fueran varia¬ 
bles normales. La unica diferencia es que ambas variables ocupan el mismo espacio 
de memoria. Si la union anonima esta en el ambito del fichero (fuera de todas las fun- 
ciones y clases), entonces se ha de declarar estatica para que tenga enlace interno. 

Aunque ahora SuperVar es segura, su utilidad es un poco dudosa porque la 
razon de utilizar una union principalmente es la de ahorrar memoria y la adicion de 
vartype hace que ocupe bastante espacio en la union (relativamente), por lo que 
la ventaja del ahorro desaparece. Hay un par de alternativas para que este esquema 
funcione. Si vartype controlara mas de una union (en el caso de que fueran del 
mismo tipo) entonces solo necesitaria uno para el grupo y no ocuparia mas memoria. 
Una aproximacion mas util es tener #ifdefs alrededor del codigo de vartype, 
el cual puede entonces garantizar que las cosas se utilizan correctamente durante 
el desarrollo y las pruebas. Si el codigo ha de entregarse, antes puede eliminar las 
sobrecargas de tiempo y memoria. 


7.4. Argumentos por defecto 

En Stash3 . h, examine los dos constructores para Stash. No parecen muy di- 
ferentes, ^verdad?. De hecho el primer constructor parece ser un caso especial del 
segundo pero con size inicializado a cero. Es un poco una perdida de tiempo y 
esfuerzo crear y mantener dos versiones diferentes de una funcion similar. 

C++ proporciona un remedio mediante los argumentos por defecto. Un argumento 
por defecto es una valor que se da en la declaration para que el compilador lo inserte 
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automaticamente en el caso de que no se proporcione en la llamada a la funcion. En 
el ejemplo de Stash, se puede reemplazar las dos funciones: 

Stash(int size); // Zero quantity 
Stash(int size, int initQuantity); 

por esta otra: 

Stash(int size, int initQuantity = 0); 

La definicion de Stash (int ) simplemente se quita; todo lo necesario esta ahora 
en la definicion de Stash ( int, int). 

Ahora, las definiciones de los dos objetos 

Stash A(100), B (100, 0); 

produciran exactamente los mismos resultados. En ambos casos se llama al mis- 
mo constructor, aunque el compilador substituye el segundo argumento de A au¬ 
tomaticamente cuando ve que que el primer argumento es un entero y no hay un 
segundo argumento. El compilador ha detectado un argumento por defecto, asi que 
sabe que todavia puede llamar a la funcion si substituye este segundo argumento, 
que es lo que usted le ha dicho que haga al no poner ese argumento. 

Los argumentos por defecto, al igual que la sobrecarga de funciones, son muy 
convenientes. Ambas caracteristicas le permiten utilizar un unico nombre para una 
funcion en situaciones diferentes. La diferencia esta en que el compilador substitu¬ 
ye los argumentos por defecto cuando no se ponen. El ejemplo anterior en un buen 
ejemplo para utilizar argumentos por defecto en vez de la sobrecarga de funciones; 
de otra modo se encuentra con dos o mas funciones que tienen signaturas y compor- 
tamientos similares. Si las funciones tienen comportamientos muy diferentes, nor- 
malmente no tiene sentido utilizar argumentos por defecto (de hecho, deberia pre- 
guntarse si dos funciones con comportamientos muy diferentes deberian llamarse 
igual). 

Hay dos reglas que se deben tener en cuenta cuando se utilizan argumentos por 
defecto. La primera es que solo los ultimos pueden ser por defecto, es decir, no puede 
poner un argumento por defecto seguido de otro que no lo es. La segunda es que una 
vez se empieza a utilizar los argumentos por defecto al realizar una llamada a una 
funcion, el resto de argumentos tambien seran por defecto (esto sigue a la primera 
regia). 

Los argumentos por defecto solo se colocan en la declaracion de la funcion (nor- 
malmente en el fichero de cabecera). El compilador debe conocer el valor por defecto 
antes de utilizarlo. Hay gente que pone los valores por defecto comentados en la de¬ 
finicion por motivos de documentacion. 

void fn(int x /* = 0 */) { // ... 


7.4.1. Argumentos de relleno 

Los argumentos de una funcion pueden declararse sin identificadores. Cuando 
esto se hace con argumentos por defecto, puede parecer gracioso. Puede encontrarse 
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con 

void f(int x, int = 0, float = 1.1); 

En C++, la definicion de la funcion tampoco necesita identificadores: 

void f (int x, int, float fit) { /* ... */ } 

En el cuerpo de la funcion, se puede hacer referenda a x y a fit, pero no al 
argumento de en medio puesto que no tiene nombre. A pesar de esto, las llamadas a 
funcion deben proporcionar un valor para este argumento de relleno: f (1) 6 f (1 , 
2, 3,0). Esta sintaxis permite poner el argumento como un argumento de relleno 
sin utilizarlo. La idea es que podria querer cambiar la definicion de la funcion para 
utilizar el argumento de relleno mas tarde, sin cambiar todo el codigo en que ya 
se invoca la funcion. Por supuesto, puede obtener el mismo resultado utilizando 
un argumento con nombre, pero en ese caso esta definiendo el argumento para el 
cuerpo de la funcion sin que este lo utilice, y la mayoria de los compiladores daran 
un mensaje de aviso, dando por hecho que usted ha cometido un error. Si deja el 
argumento sin nombre intencionadamente, evitara la advertencia. 

Mas importante, si empieza utilizando un argumento que mas tarde decide dejar 
de utilizar, puede quitarlo sin generar avisos ni fastidiar al codigo cliente que este 
utilizando la version anterior de la funcion. 


7.5. Eleccion entre sobrecarga y argumentos por 
defecto 

Tanto la sobrecarga de funciones como los argumentos por defecto resultan utiles 
para ponerle nombre a las funciones. Sin embargo, a veces puede resultar confuso 
saber que tecnica utilizar. Por ejemplo, estudie la siguiente herramienta que esta di- 
senada para tratar automaticamente bloques de memoria: 

//: CO7:Mem.h 

#ifndef MEM_H 
#define MEM_H 

typedef unsigned char byte; 

class Mem { 

byte* mem; 
int size; 

void ensureMinSize (int minSize); 
public: 

Mem () ; 

Mem( int s z); 

-Mem(); 
int msize (); 
byte* pointer(); 
byte* pointer (int minSize); 

} ; 

#endif // MEM_H ///:- 
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El objeto Mem contiene un bloque de octetos y se asegura de que tiene suficiente 
memoria. El constructor por defecto no reserva memoria pero el segundo construc¬ 
tor se asegura de que hay sz octetos de memoria en el objeto Mem. El destructor libera 
la memoria, msize ( ) le dice cuantos octetos hay actualmente en Memy pointer () 
retorna un puntero al principio de la memoria reservada (Mem es una herramienta a 
bastante bajo nivel). Hay una version sobrecargada de pointer ( ) que los progra- 
madores clientes pueden utilizar para obtener un puntero que apunta a un bloque 
de memoria con al menos el tamano minSize, y el metodo lo asegura. 

El constructor y el metodo pointer () utilizan el metodo privado ensureMin- 
Size () para incrementar el tamano del bloque de memoria (note que no es seguro 
mantener el valor de retorno de pointer () si se cambia el tamano del bloque de 
memoria). 

He aqui la implementation de la clase: 

//: C07:Mem.cpp {0} 

#include "Mem.h" 

#include <cstring> 
using namespace std; 

Mem::Mem() { mem = 0; size = 0; } 

Mem::Mem(int sz) { 
mem = 0; 
size = 0; 

ensureMinSize(sz); 

} 


Mem::-Mem() { delete []mem; } 

int Mem::msize () { return size; } 

void Mem::ensureMinSize (int minSize) { 
if (size < minSize) { 

byte* newmem = new byte[minSize] ; 

memset(newmem + size, 0, minSize - size); 

memcpy(newmem, mem, size); 

delete []mem; 

mem = newmem; 

size = minSize; 

} 

} 


byte* Mem::pointer() { return mem; } 

byte* Mem::pointer (int minSize) { 
ensureMinSize(minSize) ; 

return mem; 

} ///:- 


Puede observar que ensureMinSize () es la unica funcion responsable de re- 
servar memoria y que la utilizan tanto el segundo constructor como la segunda ver¬ 
sion sobrecargada de pointer (). Dentro de ensureSize () no se hace nada si el 
tamano es lo suficientemente grande. Si se ha de reservar mas memoria para que el 
bloque sea mas grande (que es el mismo caso cuando el bloque tiene tamano cero 
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despues del constructor por defecto), la nueva portion de mas se pone a cero utili- 
zando la funcion de la libreria estandar de C memset (), que fue presentada en el 
Capitulo 5. La siguiente llama da es a la funcion de la libreria estandar de C memc- 
py (), que en este caso copia los octetos existentes de mem a newmem (normalmente 
de una manera eficaz). Finalmente, se libera la memoria antigua y se asignan a los 
atributos apropiados la nueva memoria y su tamano. 

La clase Mem se ha disenado para su utilization como herramienta dentro de otras 
clases para simplificar su gestion de la memoria (tambien se podria utilizar para 
ocultar un sistema de gestion de memoria mas avanzada proporcionado, por ejem- 
plo, por el el sistema operativo). Esta clase se comprueba aqui con una simple clase 
de tipo string: 

//: C07:MemTest.cpp 
// Testing the Mem class 
//{L} Mem 

#include "Mem.h" 

#include <cstring> 

#include <iostream> 

using namespace std; 

class MyString { 

Mem* buf; 
public: 

MyString() ; 

MyString (char* str) ; 

-MyString() ; 

void concat (char* str); 

void print(ostrearaS os); 

} ; 


MyString::MyString() { buf = 0; } 

MyString::MyString (char* str) { 
buf = new Mem(strlen(str) + 1); 
strcpy ( (char*) buf->pointer() , str) ; 

} 


void MyString::concat (char* str) { 
if(!buf) buf = new Mem; 
strcat ( (char*) buf->pointer( 

buf->msize() + strlen (str) + 1), str); 

} 


void MyString::print(ostreamS os) { 

if(!buf) return; 

os << buf->pointer () << endl; 

} 


MyString::-MyString() { delete buf; } 

int main() { 

MyString s("My test string"); 
s.print(cout); 

s.concat ( " some additional stuff"); 
s.print(cout); 

MyString s2; 

s2.concat("Using default constructor"); 
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s2.print(cout); 
} #//:- 


Todo lo que puede hacer con esta clase es crear un My St ring, concatenar texto 
e imprimir a un ostream. La clase solo contiene un puntero a un Mem, pero note 
la diferencia entre el constructor por defecto, que pone el puntero a cero, y el se- 
gundo constructor, que crea un Mem y copia los datos dentro del mismo. La ventaja 
del constructor por defecto es que puede crear, por ejemplo, un array grande de ob- 
jetos My St ring vacios con pocos recursos, pues el tamano de cada objeto es solo 
un puntero y la unica sobrecarga en el rendimiento del constructor por defecto es 
el de asignarlo a cero. El coste de un MyString solo empieza a aumentar cuando 
concatena datos; en ese momenta el objeto Mem se crea si no ha sido creado todavia. 
Sin embargo, si utiliza el constructor por defecto y nunca concatena ningun data, la 
llamada al destructor todavia es segura porque cuando se llama a delete con un 
puntero a cero, el compilador no hace nada para no causar problemas. 

Si mira los dos constructores, en principio, podria parecer que son candidatos pa¬ 
ra utilizar argumentos por defecto. Sin embargo, si elimina el constructor por defecto 
y escribe el constructor que queda con un argumento por defecto: 

MyString(char* str = 

todo funcionara correctamente, pero perdera la eficacia anterior pues siempre se 
creara el objeto Mem. Para volver a tener la misma eficacia de antes, ha de modificar 
el constructor: 

MyString::MyString(char* str) { 

if (!*str) { // Apunta a un string ivaco 

buf = 0; 
return; 

} 

buf = new Mem(strlen(str) + 1); 
strcpy((char*)buf->pointer(), str); 

} 


Esto significa, en efecto, que el valor por defecto es un caso que ha de tratarse se- 
paradamente de un valor que no lo es. Aunque parece algo inocente con un pequeno 
constructor como este, en general esta practica puede causar problemas. Si tiene que 
tratar por separado el valor por defecto en vez de tratarlo como un valor ordinario, 
deberia ser una pista para que al final se implementen dos funciones diferentes den¬ 
tro de una funcion: una version para el caso normal y otra para el caso por defecto. 
Podria partirlo en dos cuerpos de funcion diferentes y dejar que el compilador elija. 
Esto resulta en un ligero (pero normalmente invisible) incremento de la eficacia por¬ 
que el argumento extra no se pasa y por tanto el codigo extra debido a la condicion 
condicion no se ejecuta. Mas importante es que esta manteniendo el codigo en dos 
funciones separadas en vez de combinarlas en una utilizando argumentos por de¬ 
fecto, lo que resultara en un mantenimiento mas sencillo, sobre todo si las funciones 
son largas. 

Por otro lado, considere la clase Mem. Si mira las definiciones de los dos construc¬ 
tores y las dos funciones pointer (), puede ver que la utilization de argumentos 
por defecto en ambos casos no causara que los metodos cambien. Asi, la clase podria 
ser facilmente: 
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//: CO7:Mem2.h 

#ifndef MEM2_H 
#define MEM2_H 
typedef unsigned char byte; 

class Mem { 

byte* mem; 
int size; 

void ensureMinSize (int minSize); 
public: 

Mem( int s z = 0) ; 

-Mem () ; 
int msize (); 

byte* pointer (int minSize = 0); 

} ; 

#endif // MEM2_H ///:- 


Note que la llamada a ensureMinSize ( 0 ) siempre sera bastante eficiente. 

Aunque ambos casos se basan en decisiones por motivos de eficacia, debe tener 
cuidado para no caer en la trampa de pensar solo en la eficacia (siempre fascinante). 
Lo mas importante en el diseno de una clase es la interfaz de la clase (sus miembros 
publicos, que son las que el programador cliente tiene a su disposition). Si se imple- 
menta una clase facil de utilizar y reutilizar, entonces ha tenido exito; siempre puede 
realizar ajustes para mejorar la eficacia en caso necesario, pero el efecto de una clase 
mal disenada porque el programador esta obsesionado con la eficacia puede resul- 
tar grave. Su primera preocupacion deberia ser que la interfaz tenga sentido para 
aquellos que la utilicen y para los que lean el codigo. Note que en MemTest. cpp el 
uso de MyString no cambia independientemente de si se utiliza el constructor por 
defecto o si la eficacia es buena o mala. 


7.6. Resumen 

Como norma, no deberia utilizar argumentos por defecto si hay que incluir una 
condition en el codigo. En vez de eso deberia partir la funcion en dos o mas fun- 
ciones sobrecargadas si puede. Un argumento por defecto deberia ser un valor que 
normalmente pondria ahi. Es el valor que es mas probable que ocurra, para que los 
programadores clientes puedan hacer caso omiso de el o solo lo pongan cuando no 
quieran utilizar el valor por defecto. 

El argumento por defecto se incluye para hacer mas faciles las llamadas a funcion, 
especialmente cuando esas funciones tiene muchos argumentos con valores tipicos. 
No solo es mucho mas sencillo escribir las llamadas, sino que ademas son mas sen- 
cillas de leer, especialmente si el creador de la clase ordena los argumentos de tal 
manera que aquellos que menos cambian se ponen al final del todo. 

Una utilization especialmente importante de los argumentos por defecto es cuan¬ 
do empieza con una funcion con un conjunto de argumentos, y despues de utilizarla 
por un tiempo se da cuenta que necesita ahadir mas argumentos. Si pone los nuevos 
argumentos como por defecto, se asegura de que no se rompe el codigo cliente que 
utiliza la interfaz anterior. 
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7.7. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Cree una clase Text que contenga un objeto string para que guarde el texto de 
un fichero. Pongale dos constructores: un constructor por defecto y un cons¬ 
tructor que tome un argumento de tipo string que sea el nombre del fichero 
que se vaya a abrir. Cuando se utilice el segundo constructor, abra el fichero 
y ponga su contenido en el atributo string. Anada un metodo llamado con¬ 
tents () que retorne el string para que, por ejemplo, se pueda imprimir. En 
main () abra un fichero utilizando Text e imprima el contenido en pantalla. 

2. Cree una clase Message con un constructor que tome un solo string con un 
valor por defecto. Cree un atributo privado string y asigne en el constructor el 
argumento string al atributo string. Cree dos metodos sobrecargados llamados 
print (): uno que no tome argumentos y que imprima simplemente el mensa- 
je guardado en el objeto, y el otro que tome un argumento string, que imprima 
el mensaje interno ademas del argumento. ^Tiene sentido utilizar esta aproxi- 
macion en vez de la utilizada por el constructor? 

3. Descubra como generar codigo ensamblador con su compilador y haga expe- 
rimentos para deducir el esquema de decoracion de nombres. 

4. Cree una clase que contenga cuatro metodos con 0,1, 2 y 3 argumentos de tipo 
int respectivamente. Cree un main ( ) que haga un objeto de su clase y llame 
a cada metodo. Ahora modifique la clase para que tenga solo un metodo con 
todos los argumentos por defecto. ^Eso cambia su main () ? 

5. Cree una funcion con dos argumentos y llamela desde main (). Ahora haga 
que uno de los argumentos sea un argumento de relleno (sin identificador) y 
compruebe si necesita hacer cambios en main ( ). 

6. Modifique Stash3 . h y Stash3 . cpp para que el constructor utilice argumen¬ 
tos por defecto. Pruebe el constructor haciendo dos versiones diferentes de un 
objeto Stash. 

7. Cree una nueva version de la clase Stack (del Capitulo 6) que contenga el 
constructor por defecto al igual que antes, y un segundo constructor que tome 
como argumentos un array de punteros a objetos y el tamano del array. Este 
constructor deberia recorrer el array y poner cada puntero en la pila (Stack). 
Pruebe su clase con un array de string's. 

8. Modifique SuperVar para que haya #ifdef's que engloben el codigo de v- 
artype tal como se describe en la seccion sobre enumeraciones. Cambie va- 
rtype como una enumeracion publica (sin ejemplares) y modifique print ( ) 
para que requiera un argumento de tipo vartype que le indique que tiene que 
hacer. 

9. Implemente Mem2 . h y asegurese de que la clase modificada todavia funciona 

con MemTest.cpp. 

10. Utilice la clase Mem para implementar Stash. Note que debido a que la im- 
plementacion es privada y por tanto oculta al programador cliente, no necesita 
modificar el codigo de prueba. 
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11. Anada un metodo bool movedO en la clase Mem que tome el resultado de una 11a- 
mada a pointer () y le diga si el puntero ha cambiado (debido a una reasig- 
nacion). Escriba una funcion main () que pruebe su metodo moved (). ^Tiene 
mas sentido utilizar algo como moved () o simplemente invocar pointer () 
cada vez que necesite acceder a la memoria de Mem? 
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8: Constantes 

El concepto de constante (expresion con la palabra reservada co¬ 
nst) se creo para permitir a los programadores marcar la diferencia 
entre lo que puede cambiar y lo que no. Esto facilita el control y la 
seguridad en un proyecto de programacion. 

Desde su origen, const ha sido utilizada para diferentes propositos. Mientras 
tanto FIXME:it trickled back en el lenguaje C en el que su significado cambio. Todo 
esto puede parecer un poco confuso al principio, y en este capitulo aprendera cuan- 
do, porque y como usar la palabra reservada const. Hacia el final se expone una 
disertacion sobre volatile, que es familia de const (ambos se refieren a los cambios) 
y su sintaxis es identica. 

El primer motivo para la creacion de const parece que fue eliminar el uso de la 
directiva del preprocesador #def ine para sustitucion de valores. Desde entonces se 
usa para punteros, argumentos de fund ones, tipos de retorno, objetos y funciones 
miembro. Todos ellos tienen pequenas diferencias pero su significado es conceptual- 
mente compatible. Se trataran en las siguientes secciones de este capitulo. 


8.1. Sustitucion de valores 

Cuando se programa en C, se usa libremente el preprocesador para crear macros 
y sustituir valores. El preprocesador simplemente hace un reemplazo textual y no 
realiza ninguna comprobacion de tipo. Por ello, la sustitucion de valores introduce 
pequenos problemas que se pueden evitar usando valores constantes. 

El uso mas frecuente del preprocesador es la sustitucion de valores por nombres, 
en C es algo como: 

fdefine BUFSIZE 100 


BUFSIZE es un nombre que solo existe durante el preprocesado. Por tanto, no 
ocupa memoria y se puede colocar en un fichero de cabecera para ofrecer un valor 
unico a todas las unidades que lo utilicen. Es muy importante para el mantenimiento 
del codigo el uso de sustitucion de valores en lugar de los tambien llamados «nume- 
ros magicos». Si usa numeros magicos en su codigo. no solamente impedira al lector 
conocer su procedencia o significado si no que complicara innecesariamente la edi- 
cion del codigo si necesita cambiar dicho valor. 

La mayor parte del tiempo, BUFSIZE se comportara como un valor ordinario, 
pero no siempre. No tiene informacion de tipo. Eso puede esconder errores dificiles 
de localizar. C++ utiliza const para eliminar estos problemas llevando la sustitucion 
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de valores al terreno del compilador. Ahora, puede escribir: 

const int bufsize = 100; 

Puede colocar bufsize en cualquier lugar donde se necesite conocer el valor 
en tiempo de compilacion. El compilador utiliza bufsize para hacer propagation de 
constantes 1 , que significa que el compilador reduce una expresion constante compli- 
cada a un valor simple realizando los calculos necesarios en tiempo de compilacion. 
Esto es especialmente importante en las definiciones de vectores: 

char buf [bufsize]; 

Puede usar const con todos los tipos basicos(char, int, float y double) y sus va- 
riantes (as! como clases y todo lo que vera despues en este capitulo). Debido a los 
problemas que introduce el preprocesador debera utilizar siempre const en lugar 
de #def ine para la sustitucion de valores. 


8.1.1. const en archivos de cabecera 

Para poder usar const en lugar de #define, debe ser posible colocar las defi¬ 
niciones const en los archivos de cabecera como se hacia con los #def ine. De este 
modo, puede colocar la definicion de una constante en un unico lugar y distribuirla 
incluyendo el archivo de cabecera en las unidades del programa que la necesiten. 
Una constante en C++ utiliza enlazado interno, es decir, es visible solo desde el ar¬ 
chivo donde se define y no puede verse en tiempo de enlazado por otros modulos. 
Debera asignar siempre un valor a las constantes cuando las defina, excepto cuando 
explicitamente use la declaracion extern: 

extern const int bufsize; 

Normalmente el compilador de C++ evita la asignacion de memoria para las 
constantes, pero en su lugar ocupa una entrada en la tabla de simbolos. Cuando 
se utiliza extern con una constante, se fuerza el alojamiento en memoria (esto tam- 
bien ocurre en otros casos, como cuando se solicita la direccion de una constante). 
El uso de la memoria debe hacerse porque extern dice «usa enlazado externo», es 
decir, que varios modulos deben ser capaces de hacer referenda al elemento, algo 
que requiere su almacenamiento en memoria. 

Por lo general, cuando extern no forma parte de la definicion, no se pide me¬ 
moria. Cuando la constante se utiliza simplemente se incorpora en tiempo de com¬ 
pilacion. 

El objetivo de no almacenar en memoria las constantes tampoco se cumple con 
estructuras complicadas. Cuando el compilador se ve obligado a pedir memoria no 
puede realizar propagation de constantes (ya que el compilador no tiene forma de co¬ 
nocer con seguridad que valor debe almacenar; si lo conociese, no necesitaria pedir 
memoria). 

Como el compilador no siempre puede impedir el almacenamiento para una 
constante, las definiciones de constantes utilizan enlace interno, es decir, se enlazan 
solo con el modulo en que se definen. En caso contrario, los errores de enlace po- 
drian ocurrir con las expresiones constantes complicadas ya que causarian peticion 


1 N. del T.: del ingles constant folding 
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de almacenamiento en diferentes modulos. Entonces, el enlazador veria la misma 
definicion en multiples archivos objeto, lo que causaria un error en el enlace. Como 
las constantes utilizan enlace interno, el enlazador no intenta enlazar esas definicio- 
nes a traves de los modulos, y asi no hay colisiones. Con los tipos basicos, que son 
los se ven involucrados en la mayoria de los casos, el compilador siempre realiza 
propagation de constantes. 


8.1.2. constantes seguras 

El uso de las constantes no esta limitado a la sustitucion de los #define por 
expresiones constantes. Si inicializa una variable con un valor que se produce en 
tiempo de execution y sabe que no cambiara durante la vida de la variable, es una 
buena practica de programacion hacerla constante para que de ese modo el com¬ 
pilador produzca un mensaje de error si accidentalmente alguien intenta modificar 
dicha variable. Aqui hay un ejemplo: 

//: C08:Safecons.cpp 
// Using const for safety 

#include <iostream> 

using namespace std; 

const int i = 100; // Typical constant 
const int j = i + 10; // Value from const expr 
long address = (long)&j; // Forces storage 
char buf[ j + 10]; // Still a const expression 

int main ( ) { 

cout << "type a character & CR:"; 

const char c = cin.getO; // Can't change 

const char c2 = c + 'a' ; 

cout << c2; 

// . . . 

} ///:- 


Puede ver que i es una constante en tiempo de compilation, pero j se calcula 
a partir de i. Sin embargo, como i es una constante, el valor calculado para j es 
una expresion constante y es en si mismo otra constante en tiempo de compilation. 
En la siguiente linea se necesita la direction de j y por lo tanto el compilador se ve 
obligado a pedir almacenamiento para j. Ni siquiera eso impide el uso de j para 
determinar el tamano de buf porque el compilador sabe que j es una constante y 
que su valor es valido aunque se asigne almacenamiento, ya que eso se hace para 
mantener el valor en algun punto en el programa. 

En main (), aparece un tipo diferente de constante en el identificador c, porque el 
valor no puede ser conocido en tiempo de compilation. Eso significa que se requiere 
almacenamiento, y por eso el compilador no intenta mantener nada en la tabla de 
simbolos (el mismo comportamiento que en C). La initialization debe ocurrir, aun 
asi, en el punto de la definicion, y una vez que ocurre la initialization, el valor ya no 
puede ser cambiado. Puede ver que c2 se calcula a partir de c y ademas las reglas de 
ambito funcionan para las constantes igual que para cualquier otro tipo, otra ventaja 
respecto al uso de #def ine. 

En la practica, si piensa que una variable no deberia cambiar, deberia hacer que 
fuese una constante. Esto no solo da seguridad contra cambios inadvertidos, tambien 
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permite al compilador generar codigo mas eficiente ahorrando espacio de almacena- 
miento y lecturas de memoria en la execution del programa. 


8.1.3. Vectores 

Es posible usar constantes para los vectores, pero practicamente esta dando por 
hecho que el compilador no sera lo suficientemente sofisticado para mantener un 
vector en la tabla de simbolos, as! que le asignara espacio de almacenamiento. En 
estas situaciones, const significa «un conjunto de datos en memoria que no pueden 
modificarse». En cualquier caso, sus valores no puede usarse en tiempo de compila¬ 
tion porque el compilador no conoce en ese momento los contenidos de las variables 
que tienen espacio asignado. En el codigo siguiente puede ver algunas declaraciones 
incorrectas. 

//: C08:Constag.cpp 
// Constants and aggregates 

const int it] = { 1, 2, 3, 4 }; 

//! float f[i[3]]; // Illegal 

struct S { int i, j; }; 

const Ss[] ={ { 1, 2 }, {3,4}}; 

//! double d[s[l].j]; // Illegal 
int main)) {} ///:- 


En la definicion de un vector, el compilador debe ser capaz de generar codigo 
que mueva el puntero de pila para dar cabida al vector. En las definiciones inco¬ 
rrectas anteriores, el compilador se queja porque no puede encontrar una expresion 
constante en la definicion del tamano del vector. 


8.1.4. Diferencias con C 

Las constantes se introdujeron en las primeras versiones de C++ mientras la es- 
pecificacion del estandar C estaba siendo terminada. Aunque el comite a cargo de C 
decidio entonces incluir const en C, por alguna razon, vino a significar para ellos 
«una variable ordinaria que no puede cambiarse». En C, una constante siempre ocu- 
pa espacio de almacenamiento y su ambito es global. El compilador C no puede 
tratar const como una constante en tiempo de compilacion. En C, si escribe: 

const int bufsize = 100; 
char buf[bufsize]; 

aparecera un error, aunque parezca algo razonable. bufsize esta guardado en 
algun sitio y el compilador no conoce su valor en tiempo de compilacion. Opcional- 
mente puede escribir: 

const int bufsize; 

en C, pero no en C++, y el compilador C lo acepta como una declaration que 
indica que se almacenara en alguna parte. Como C utiliza enlace externo para las 
constantes, esa semantica tiene sentido. C++ utiliza normalmente enlace interno, asi 
que, si quiere hacer lo mismo en C++, debe indicar expresamente que se use enlace 
externo usando extern. 
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extern const int bufsize; // es odeclaracin, no odefinicin 


Esta declaracion tambien es valida en C. 

En C++, const no implica necesariamente almacenamiento. En C, las constantes 
siempre necesitan almacenamiento. El hecho de que se necesite almacenamiento o no 
depende de como se use la constante. En general, si una constante se usa simplemen- 
te para reemplazar un numero por un nombre (como hace #define), entonces no 
requiere almacenamiento. Si es as! (algo que depende de la complejidad del tipo de 
dato y de lo sofisticacion del compilador) los valores pueden expandirse en el codigo 
para conseguir mayor eficiencia despues de la comprobacion de los tipos, no como 
con #def ine. Si de todas formas, se necesita la direccion de una constante (aun des- 
conocida, para pasarla a una funcion como argumento por referenda) o se declara 
como extern, entonces se requiere asignar almacenamiento para la constante. 

En C++, una constante que este definida fuera de todas las funciones tiene ambi- 
to de archivo (es decir, es inaccesible fuera del archivo). Esto significa que usa enlace 
interno. Esto es diferente para el resto de identificadores en C++ (y que las constan¬ 
tes en C) que utilizan siempre enlace externo. Por eso, si declara una constante con 
el mismo nombre en dos archivos diferentes y no toma sus direcciones ni los define 
como extern, el compilador C++ ideal no asignara almacenamiento para la cons¬ 
tante, simplemente la expandira en el codigo. Como las constantes tienen implicito 
el ambito a su archivo, puede ponerlas en un archivo de cabecera de C++ sin que 
origine conflictos en el enlace. 

Dado que las constante en C++ utilizan por defecto enlace interno, no puede defi- 
nir una constante en un archivo y utilizarla desde otro. Para conseguir enlace externo 
para la constante y asi poder usarla desde otro archivo, debe definirla explicitamente 
como extern, algo asi: 

extern const int x = 1; // odefinicin, no odeclaracin 


Senalar que dado un identificador, si se dice que es extern, se fuerza el alma¬ 
cenamiento para la constante (aunque el compilador tenga la opcion de hacer la ex¬ 
pansion en ese punto). La inicializacion establece que la sentencia es una definicion, 
no una declaracion. La declaracion: 

extern const int x; 


en C++ significa que la definicion existe en algun sitio (mientras que en C no 
tiene porque ocurrir asi). Ahora puede ver porque C++ requiere que las definiciones 
de constantes incluyan la inicializacion: la inicializacion diferencia una declaracion 
de una definicion (en C siempre es una definicion, aunque no este inicializada). Con 
una declaracion const extern, el compilador no hace expansion de la constante 
porque no conoce su valor. 

La aproximacion de C a las constantes es poco util, y si quiere usar un valor sim- 
bolico en una expresion constante (que deba evaluarse en tiempo de compilacion) 
casi esta obligado a usar #def ine. 
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8.2. Punteros 

Los punteros pueden ser constantes. El compilador pondra mas esfuerzo aun 
para evitar el almacenamiento y hacer expansion de constantes cuando se trata de 
punteros constantes, pero estas caracteristicas parecen menos utiles en este caso. Lo 
mas importante es que el compilador le avisara si intenta cambiar un puntero cons- 
tante, lo que representa un buen elemento de seguridad. Cuando se usa const con 
punteros tiene dos opciones: se pueden aplicar a lo que apunta el puntero o a la pro- 
pia direccion almacenada en el puntero. La sintaxis es un poco confusa al principio 
pero se vuelve comodo con la practica. 


8.2.1. Puntero a constante 

El truco con la definicion de un puntero, al igual que con una definicion com- 
plicada, es leerla empezando por el identificador e ir analizando la definicion hacia 
afuera. El especificador const esta ligado a la cosa «mas cercana». Asi que si se 
quiere impedir cambios en el elemento apuntado, escribe una definicion parecida a 
esta: 

const int* u; 

Empezando por el identificador, se lee «u es un puntero, que apunta a un entero 
constante». En este caso no se requiere inicializacion porque esta diciendo que u pue- 
de apuntar a cualquier cosa (es decir, no es constante), pero la cosa a la que apunta 
no puede cambiar. 

Ahora viene la parte confusa. Podria pensar que hacer el puntero inalterable en 
si mismo, es decir, impedir cualquier cambio en la direccion que contiene u, es tan 
simple como mover la palabra const al otro lado de la palabra int: 

int const* v; 

y pensar que esto deberia leerse «v es un puntero constante a un entero». Sin em¬ 
bargo, la forma de leerlo es «v es un puntero ordinario a un entero que es constante». 
Es decir, la palabra const se refiere de nuevo al entero y el efecto es el mismo que 
en la definicion previa. El hecho de que estas definiciones sean equivalentes es con- 
fuso, para evitar esta confusion por parte del lector del codigo, deberia cenirse a la 
primera forma. 


8.2.2. Puntero constante 

Para conseguir que el puntero sea inalterable, debe colocar el especificador con¬ 
st a la derecha del *: 

int d = 1; 

int * const w = &d; 


Ahora, se lee «w es un puntero constate, y apunta a un entero». Como el puntero 
en si es ahora una constante, el compilador obliga a darle un valor inicial que no 
podra alterarse durante la vida del puntero. En cualquier caso, puede cambiar el 
valor de lo que apunta el puntero con algo como: 
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*w = 2; 

Tambien puede hacer un puntero constante a un elemento constante usando una 
de las formas siguientes: 

int d = 1; 

const int* const x = &d; // (1) 
int const* const x2 = &d; // (2) 

Ahora ni el puntero ni el elemento al que apunta pueden modificarse. 

Algunos argumentan que la segunda forma es mas consistente porque el const 
se coloca siempre a la derecha de lo que afecta. Debe decidir que forma resulta mas 
clara para su estilo de codificacion particular. 

Algunas lfneas de un archivo susceptible de ser compilado. 


//: C08:ConstPointers.cpp 



const int* 

u; 



int const* 

v; 



int d = 1; 




int* const 

T? 

II 

5 



const int* 

const x = &d; 

// 

(1) 

int const* 

const x2 = &d; 

// 

(2) 

int main () 

{} !U%~ 




Formato 

Este libro sigue la norma de poner solo una definicion de puntero por ltnea, e 
inicializar cada puntero en el punto de definicion siempre que sea posible. Por eso, 
el estilo es colocar el * al lado del tipo: 

int* u = &i; 


como si int* fuese un tipo de dato basico. Esto hace que el codigo sea mas facil de 
leer, pero desafortunadamente, esta no es la forma en que funciona. El «*» se refiere 
al identificador no al tipo. Se puede colocar en cualquier sitio entre el nombre del 
tipo y el identificador. De modo que puede hacer esto: 

int *u=&i, v = 0; 


donde se crea un int* u y despues un int v (que no es puntero). Como esto 
puede parecer confuso a los lectores, es mejor utilizar el estilo mostrado en este libro. 


8.2.3. Asignacion y comprobacion de tipos 

C++ es muy exigente en lo referente a la comprobacion de tipos y esto se extiende 
a la asignacion de punteros. Puede asignar la direccion de una variable no constan¬ 
te a un puntero constante porque simplemente esta prometiendo no cambiar algo 
que puede cambiarse. De todos modos, no puede asignar la direccion de una varia¬ 
ble constante a un puntero no constante porque entonces esta diciendo que podria 
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modificar la variable a traves del puntero. Por supuesto, siempre puede usar «un 
molde» para forzar la asignacion, pero eso es siempre una mala practica de progra- 
macion ya que rompe la consistencia de la variable ademas del grado de seguridad 
que ofrece el especificador const. Por ejemplo: 

//: C08:PointerAssignment.cpp 

int d = 1; 

const int e = 2 ; 

int* u = &d; // OK — d not const 
//! int* v = &e; // Illegal — e const 
int* w = (int*)&e; // Legal but bad practice 
int main)) {} ///:- 


Aunque C++ ayuda a evitar errores, no le protege de usted mismo si se empena 
en romper los mecanismos de seguridad. 

Literates de cadena 

C++ no es tan estricto con los literales en lo referente a constantes. Puede escribir: 

char * cp = "howdy"; 


y el compilador lo aceptara sin objecion. Tecnicamente esto supone un error por- 
que el literal de cadena («howdy» en este caso) se crea por el compilador como un 
vector de caracteres constante, y el resultado del vector de caracteres entrecomillado 
es la direccion de memoria del primer elemento. Si se modifica uno de los caracteres 
del vector en tiempo de ejecucion es un error, aunque no todos los compiladores lo 
imponen correctamente. 

Asi que los literales de cadena son arrays de caracteres constantes. Por supuesto, 
el compilador le permite tratarlos como no constantes porque existe mucho codigo 
C que depende de ello. De todas formas, si intenta cambiar los valores de un literal, 
el resultado no esta definido, y probablemente funcione en muchos computadores. 

Si quiere poder modificar una cadena, debe ponerla en un vector: 

char cp[] = "howdy"; 


Como los compiladores a menudo no imponen la diferencia no tiene porque re- 
cordar que debe usar esta la ultima forma y la cuestion pasa a ser algo bastante sutil. 


8.3. Argumentos de funciones y valores de retorno 

El uso del especificador const con argumentos de funciones y valores de retorno 
es otro lugar donde el concepto de constante puede resultar confuso. Si esta pasando 
variables por valor, utilizar const no tiene significado para el cliente (significa que el 
argumento que se pasa no puede modificarse en la funcion). Si esta devolviendo una 
variable de un tipo derivado y utiliza el especificador const, significa que el valor 
de retorno no puede modificarse. Si pasa o devuelve direcciones, const impide que 
el destinatario de la direccion pueda modificarse. 



'Volumenl" — 2012/1/12 — 13:52 — page 231 — #269 


8.3. Argumentos de funciones y valores de retorno 


8.3.1. Paso por valor constante 

Puede indicar que los argumentos de funciones son constantes cuando se pasa 
por valor como: 

void fl(const int i) { 
i++; // ilegal 

} 


pero, <ique significa esto? Esta impidiendo que el valor de la variable original 
pueda ser cambiado en la funcion f 1 (). De todos formas, como el argumento se pasa 
por valor, es sabido que inmediatamente se hace una copia de la variable original, asi 
que dicha restriction se cumple implicitamente sin necesidad de usar el especificador 

const. 

Dentro de la funcion, const si toma un significado: El argumento no se puede 
cambiar. Asi que, en realidad, es una herramienta para el programador de la funcion, 
no para el que la usa. 

Para evitar la confusion del usuario de la funcion, puede hacer que el argumento 
sea constante dentro de la funcion en lugar de en la lista de argumentos. Podria 
hacerlo con un puntero, pero la sintaxis mas adecuada para lograrlo es la referenda, 
algo que se tratara en profundidad en el capitulo 11[FIXME:XREF]. 

Brevemente, una referencia es como un puntero constante que se dereferencia 
automaticamente, asi que es como tener un alias de la variable. Para crear una refe¬ 
rencia, debe usar el simbolo & en la definicion. De ese modo se tiene una definicion 
libre de confusiones. 

void f2(int ic) { 

const int &i = ic; 

i++; // ilegal (error de ocompilacin) 

} 


De nuevo, aparece un mensaje de error, pero esta vez el especificador const no 
forma parte de la cabecera de la funcion, solo tiene sentido en la implementation de 
la funcion y por la tanto es invisible para el cliente. 


8.3.2. Retorno por valor constante 

Algo similar ocurre con los valores de retorno. Si dice que el valor de retorno de 
una funcion es constante: 

const int g (); 

esta diciendo que el valor de la variable original (en el ambito de la funcion) no 
se modificara. Y de nuevo, como lo esta devolviendo por valor, es la copia lo que se 
retorna, de modo que el valor original nunca se podra modificar. 

En principio, esto puede hacer suponer que el especificador const tiene poco 
significado. Puede ver la aparente falta de sentido de devolver constantes por valor 
en este ejemplo: 


//: C08:Constval.cpp 
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// Returning consts by value 

// has no meaning for built-in types 

int f3() { return 1; } 

const int f 4() { return 1; } 

int main () { 

const int j = f3 (); // Works fine 
int k = f4 (); // But this works fine too! 
} ///:~ 


Para los tipos basicos, no importa si el retorno es constante, asi que deberia evitar 
la confusion para el programador cliente y no utilizar const cuando se devuelven 
variables de tipos basicos por valor. 

Devolver por valor como constante se vuelve importante cuando se trata con 
tipos definidos por el programador. Si una funcion devuelve un objeto por valor 
como constante, el valor de retorno de la funcion no puede ser un recipiente 2 

Por ejemplo: 

//: C08:ConstReturnValues.cpp 

// Constant return by value 

// Result cannot be used as an lvalue 

class X { 
int i; 
public: 

X ( int i i = 0) ; 
void modify() ; 

} ; 


X::X(int ii) { i — ii; } 
void X::modify() { i++; } 

X f 5 () { 

return X(); 

} 

const X f6() { 

return X(); 

1 


void f7 (X& x) { // Pass by non-const reference 
x.modify(); 

} 


int main() { 

f5() = X(l); // OK — non-const return value 

f5().modify(); // OK 

//! f7(f5()); // Causes warning or error 
// Causes compile-time errors: 

//! f 6 () = X (1) ; 

//! f6().modify(); 

2 N. del T.: «recipiente» corresponde con el termino lvalue que se refiere a una variable que puede ser 
modificada o a la que se le puede asignar un valor. 
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//! f7(f6 ()) ; 
} ///:~ 


f 5 () devuelve un objeto de clase X no constante, mientras que f 6 () devuelve 
un objeto de clase X pero constante. Solo el valor de retorno por valor no constante 
se puede usar como recipiente. 

Por eso, es importante usar const cuando se devuelve un objeto por valor si 
quiere impedir que se use como recipiente. 

La razon por la que const no tiene sentido cuando se usa para devolver por 
valor variables de tipos del lenguaje es que el compilador impide automaticamente 
el uso de dichos tipos como recipiente, ya que devuelve un valor, no una variable. 
Solo cuando se devuelven objetos por valor de tipos definidos por el programador 
esta funcionalidad toma sentido. 

La funcion f 7 () toma como argumento una referenda no constante (la referen¬ 
da es una forma adicional para manejar direcciones en C++ y se trata en el [FIX- 
ME:XREF:capitulo 11]). Es parecido a tomar un puntero no constante, aunque la sin- 
taxis es diferente. La razon por la que no compila es por la creation de un temporario. 

Temporaries 

A veces, durante la evaluation de una expresion, el compilador debe crear obje¬ 
tos temporales (temporaries). Son objetos como cualquier otro: requieren espacio de 
almacenamiento y se deben construir y destruir. La diferencia es que nunca se ven, 
el compilador es el responsable de decidir si se necesitan y los detalles de su exis- 
tencia. Una particularidad importante de los temporaries es que siempre son cons- 
tantes. Como normalmente no manejara objetos temporaries, hacer algo que cambie 
un temporario es casi seguro un error porque no sera capaz de usar esa information. 
Para evitar esto, el compilador crea todos los temporaries como objetos constantes, 
de modo que le avisara si intenta modificarlos. 

En el ejemplo anterior, f 5 () devuelve un objeto no constante. Pero en la expre¬ 
sion: 

f7 (f5 () ) ; 

el compilador debe crear un temporario para albergar el valor de retorno de f- 
5 () para que pueda ser pasado a f 7 (). Esto funcionaria bien si f 7 () tomara su 
argumento por valor; entonces el temporario se copiaria en f 7 () y no importaria lo 
que se pase al temporario X. 

Sin embargo, f 7 () toma su argumento por referencia, lo que significa que to¬ 
ma la direction del temporario X. Como f 7 () no toma su argumento por referencia 
constante, tiene permiso para modificar el objeto temporario. Pero el compilador sa- 
be que el temporario desaparecera en cuanto se complete la evaluation de la expre¬ 
sion, y por eso cualquier modification hecha en el temporario se perdera. Haciendo 
que los objetos temporaries sean constantes automaticamente, la situation causa un 
error de compilation de modo que evitara cometer un error muy dificil de localizar. 

En cualquier caso, tenga presente que las expresiones siguientes son correctas: 

f 5 () = X(l) ; 
f5().modify(); 



0 


0 


0 


"Volumenl" — 2012/1/12 — 13:52 — page 234 — #272 


0 


Capitulo 8. Constantes 


Aunque son aceptables para el compilador, en realidad son problematicas. f 5 () 
devuelve un objeto de clase X, y para que el compilador pueda satisfacer las expresio- 
nes anteriores debe crear un temporario para albergar el valor de retorno. De modo 
que en ambas expresiones el objeto temporario se modifica y tan pronto como la 
expresion es evaluada el temporario se elimina. Como resultado, las modificaciones 
se pierden, asi que probablemente este codigo es erroneo, aunque el compilador no 
diga nada al respecto. Las expresiones como estas son suficientemente simples como 
para detectar el problema, pero cuando las cosas son mas complejas los errores son 
mas dificiles de localizar. 

La forma de preservar la constancia de los objetos se muestra mas adelante en 
este capitulo. 


8.3.3. Paso y retorno de direcciones 

Si pasa o retorna una direccion (ya sea un puntero o una referenda), el programa- 
dor cliente puede recoger y modificar el valor al que apunta. Si hace que el puntero 
o referenda sea constante, impedira que esto suceda, lo que puede ahorrarle proble- 
mas. De hecho, cada vez que se pasa una direccion como parametro a una funcion, 
deberia hacerla constante siempre que sea posible. Si no lo hace, esta excluyendo la 
posibilidad de usar la funcion con constantes. 

La opcion de devolver un puntero o referencia constante depende de lo que quie- 
ra permitir hacer al programador cliente. Aqui se muestra un ejemplo que demuestra 
el uso de punteros constantes como argumentos de funciones y valores de retorno. 

//: C08:ConstPointer.cpp 
// Constant pointer arg/return 

void t(int*) {} 

void u (const int* cip) { 

//! *cip =2; // Illegal — modifies value 
int i = *cip; // OK -- copies value 
//! int* ip2 = cip; // Illegal: non-const 
} 


const char* v() { 

// Returns address of static character array: 
return "result of function v()"; 

} 


const int* const w() { 

static int i; 
return &i; 


int main () { 

int x = 0; 
int* ip = &x; 
const int* cip = &x; 

t(ip); // OK 

//! t (cip); // Not OK 
u(ip); // OK 

u(cip); // Also OK 
//! char* cp = v(); // Not OK 


234 


0 


0 


-0 


0 
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const char* ccp = v(); //OK 
//! int* ip2 = w(); // Not OK 

const int* const ccip = w(); // OK 
const int* cip2 = w(); // OK 

//! *w() =1; // Not OK 

} /// : ~ 


La funcion t () toma un puntero no-constante ordinario como argumento, y u () 
toma un puntero constante. En el cuerpo de u () puede ver un intento de modificar 
el valor de un puntero constante, algo incorrecto, pero puede copiar su valor en una 
variable no constante. El compilador tambien impide crear un puntero no constante 
y almacenar en el la direccion contenida en un puntero constante. 

Las funciones v () y w () prueban las semanticas de retorno de valores. v () de- 
vuelve un const char* que se crea a partir de un literal de cadena. Esta sentencia en 
realidad genera la direccion del literal una vez que el compilador lo crea y almace- 
na en area de almacenamiento estatica. Como se ha dicho antes, tecnicamente este 
vector de caracteres es una constante, como bien indica el tipo de retorno de v (). 

El valor de retorno de w () requiere que tanto el puntero como lo que apunta sean 
constantes. Como en v () , el valor devuelto por w () es valido una vez terminada la 
funcion solo porque es estatico. Nunca debe devolver un puntero a una variable local 
pues se almacenan en la pila y al terminar la funcion los datos de la pila desaparecen. 
Lo que si puede hacer es devolver punteros que apuntan a datos almacenados en el 
monton (heap), pues siguen siendo validos despues de terminar la funcion. 

En main () se prueban las funciones con varios argumentos. Puede ver que t () 
aceptara como argumento un puntero ordinario, pero si intenta pasarle un puntero 
a una constante, no hay garantla de que no vaya a modificarse el valor de la variable 
apuntada; por ello el compilador lo indica con un mensaje de error, u () toma un 
puntero a constante, as! que puede aceptar los dos tipos de argumentos. Por eso una 
funcion que acepta un puntero a constante es mas general que una que acepta un 
puntero ordinario. 

Como es logico, el valor de retorno de v () solo se puede asignar a un puntero a 
constante. Tambien era de esperar que el compilador rehuse asignar el valor devuel¬ 
to por w () a un puntero ordinario, y que si acepte un const int* const, pero podrla 
sorprender un poco que tambien acepta un const int*, que no es exactamente el tipo 
de retorno declarado en la funcion. De nuevo, como el valor (que es la direccion con¬ 
tenida en el puntero) se copia, el requisito de que la variable original permanezca 
inalterable se cumple automaticamente. Por eso, el segundo const en la declara¬ 
tion const int* const solo se aplica cuando lo use como recipiente, en cuyo caso el 
compilador lo impedirla. 

Criterio de paso de argumentos 

En C es muy comun el paso por valor, y cuando se quiere pasar una direccion 
la unica posibilidad es usar un puntero 3 . Sin embargo, ninguno de estos modos es 
el preferido en C++. En su lugar, la primera option cuando se pasa un parametro 
es hacerlo por referenda o mejor aun, por referenda constante. Para el cliente de la 
funcion, la sintaxis es identica que en el paso por valor, de ese modo no hay con¬ 
fusion posible con los punteros, no hay que pensar en terminos de punteros. Para 

3 Algunos autores dicen que todo en C se pasa por valor, ya que cuando se pasa un puntero se hace 
tambien una copia (de modo que el puntero se pasa por valor). En cualquier caso, hacer esta precision 
puede, en realidad, confundir la cuestion. 
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el creador de una funcion, pasar una direccion es siempre mas eficiente que pasar 
un objeto completo, y si pasa por referenda constante significa que la funcion no 
podra cambiar lo almacenado en esa direccion, asi que el efecto desde el punto de 
vista del programador cliente es lo mismo que el paso por valor (sin embargo es mas 
eficiente). 

A causa de la sintaxis de las referencias (para el cliente es igual que el paso por 
valor) es posible pasar un objeto temporario a una funcion que toma una referencia 
constante, mientras que nunca puede pasarse un objeto temporario a una funcion 
que toma un puntero (con un puntero, la direccion debe darse explicitamente). Asi 
que con el paso por referencia se produce una nueva situacion que nunca ocurre en 
C: un temporario, que es siempre constante, puede pasar su direccion a una funcion 
(una funcion puede tomar por argumento la direccion de un temporario). Esto es 
asi porque, para permitir que los temporaries se pasen por referencia, el argumento 
debe ser una referencia constante. El siguiente ejemplo lo demuestra: 


//: C08:ConstTemporary.epp 
// Temporaries are const 

class X {}; 

X f() { return X(); } // Return by value 


void gl(X&) {} // Pass by non-const reference 
void g2 (const X&) {} // Pass by const reference 


int main() 

// Error: 

//! gl(f() 
// OK: g2 
g2 (f () ) ; 

} ///:~ 


const temporary created by 

r 

takes a const reference: 


f 0 : 


f () retorna un objeto de la clase X por valor. Esto significa que cuando tome el 
valor de retorno y lo pase inmediatamente a otra funcion como en las llamadas a 
gl () y g2 (), se crea un temporario y los temporaries son siempre constantes. Por 
eso, la llama da a gl () es un error pues gl () no acepta una referencia constante, 
mientras que la llamada a g2 () si es correcta. 


8.4. Clases 

Esta seccion muestra la forma en la que se puede usar el especificador const con 
las clases. Puede ser interesante crear una constante local a una clase para usarla en 
expresiones constantes que seran evaluadas en tiempo de compilacion. Sin embargo, 
el significado del especificador const es diferente para las clases 4 , de modo que 
debe comprender las opciones adecuadas para crear miembros constantes en una 
clase. 

Tambien se puede hacer que un objeto completo sea constante (y como se ha vis- 
to, el compilador siempre hace constantes los objetos temporaries). Pero preservar la 
consistencia de un objeto constante es mas complicado. El compilador puede asegu- 
rar la consistencia de las variables de los tipos del lenguaje pero no puede vigilar la 

4 N. del T.: Esto se conoce como polisemia del lenguaje 
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complejidad de una clase. Para garantizar dicha consistencia se emplean las funcio- 
nes miembro constantes; que son las unicas que un objeto constante puede invocar. 

8.4.1. const en las clases 

Uno de los lugares donde interesa usar const es para expresiones constantes 
dentro de las clases. El ejemplo tipico es cuando se define un vector en una clase y 
se quiere usar const en lugar de #define para establecer el tamano del vector y 
para usarlo al calcular datos concernientes al vector. El tamano del vector es algo 
que desea mantener oculto en la clase, asi que si usa un nombre como size, por 
ejemplo, se podria usar el mismo nombre en otra clase sin que ocurra un conflicto. El 
preprocesador trata todos los #def ine de forma global a partir del punto donde se 
definen, algo que const permite corregir de forma adecuada consiguiendo el efecto 
deseado. 

Se podria pensar que la eleccion logica es colocar una constante dentro de la 
clase. Esto no produce el resultado esperado. Dentro de una clase const recupera 
un poco su significado en C. Asigna espacio de almacenamiento para cada variable 
y representa un valor que es inicializado y ya no se puede cambiar. El uso de una 
constante dentro de una clase significa «Esto es constante durante la vida del objeto». 
Por otra parte, en cada objeto la constante puede contener un valor diferente. 

Por eso, cuando crea una constante ordinaria (no estatica) dentro de una clase, no 
puede darle un valor inicial. Esta inicializacion debe ocurrir en el constructor. Como 
la constante se debe inicializar en el punto en que se crea, en el cuerpo del cons¬ 
tructor la constante debe estar ya inicializada. De otro modo, le quedaria la opcion 
de esperar hasta algun punto posterior en el constructor, lo que significaria que la 
constante no tendria valor por un momento. Y nada impediria cambiar el valor de la 
constante en varios sitios del constructor. 

La lista de inicializacion del constructor. 

Un punto especial de inicializacion es la llamada «lista de inicializacion del cons¬ 
tructor y fue pensada en un principio para su uso en herencia (tratada en el [FIX- 
ME:XREF:capitulo 14]). La lista de inicializacion del constructor (que como su nom¬ 
bre indica, solo aparece en la definicion del constructor) es una lista de llamadas a 
constructores que aparece despues de la lista de argumentos del constructor y antes 
de abrir la Have del cuerpo del constructor. Se hace ast para recordarle que las ini¬ 
cializacion de la lista sucede antes de ejecutarse el constructor. Ese es el lugar donde 
poner las inicializaciones de todas las constantes de la clase. El modo apropiado para 
colocar las constantes en una clase se muestra a continuacion: 

//: C08:Constlnitialization.cpp 
// Initializing const in classes 

#include <iostream> 

using namespace std; 

class Fred { 

const int size; 
public: 

Fred (int sz); 
void print (); 

} ; 

Fred::Fred (int sz) : size(sz) {} 
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void Fred::print() { cout << size << endl; } 

int main() { 

Fred a(l), b(2), c(3); 
a.printO, b.print(), c.print (); 

} ///:- 


El aspecto de la lista de inicializacion del constructor mostrada arriba puede crear 
confusion al principio porque no es usual tratar los tipos del lenguaje como si tuvie- 
ran constructores. 

Constructores para los tipos del lenguaje 

Durante el desarrollo del lenguaje se puso mas esfuerzo en hacer que los tipos 
definidos por el programador se pareciesen a los tipos del lenguaje, pero a veces, 
cuando se vio util se hizo que los tipos predefinidos ( built-in se pareciesen a los defi¬ 
nidos por el programador. En la lista de inicializacion del constructor, puede tratar a 
los tipos del lenguaje como si tuvieran un constructor, como aqui: 

//: CO8:BuiltlnTypeConstructors.cpp 

#include <iostream> 

using namespace std; 

class B { 
int i; 
public: 

B(int ii); 
void print () ; 

} ; 

B::B(int ii) : i (ii) {} 

void B::print() { cout << i << endl; } 

int main ( ) { 

B a (1) , b (2) ; 
float pi(3.14159); 
a.printO; b.printO; 
cout << pi << endl; 

1 ///:~ 


Esto es especialmente critico cuando se inicializan atributos constantes porque se 
deben inicializar antes de entrar en el cuerpo de la funcion. Tiene sentido extender es- 
te «constructor» para los tipos del lenguaje (que simplemente significan asignacion) 
al caso general que es por lo que la definicion float funciona en el codigo anterior. 
A menudo es util encapsular un tipo del lenguaje en una clase para garantizar la 
inicializacion con el constructor. Por ejemplo, aqui hay una clase Integer: 

//: C08:EncapsulatingTypes.cpp 

#include <iostream> 

using namespace std; 

class Integer { 
int i; 
public: 
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Integer (int ii = 0) ; 
void print(); 

}; 

Integer::Integer (int ii) : i(ii) {} 

void Integer::print() { cout << i << ' '; } 

int main() { 

Integer i [100]; 
for(int j = 0; j < 100; j++) 
i[j] .print () ; 

} ///:- 


El vector de enteros declarado en main () se inicializa automaticamente a cero. 
Esta inicializacion no es necesariamente mas costosa que un bucle f or o memset (). 
Muchos compiladores lo optimizan facilmente como un proceso muy rapido. 


8.4.2. Constantes en tiempo de compilacion dentro de cla¬ 
ses 

El uso anterior de const es interesante y probablemente util en muchos casos, 
pero no resuelve el programa original de «como hacer una constante en tiempo de 
compilacion dentro de una clase». La respuesta requiere del uso de un especificador 
adicional que se explicara completamente en el [FIXME:capitulo 10]: static. El es¬ 
pecificador static, en esta situacion significa «hay solo una instancia a pesar de 
que se creen varios objetos de la clase» que es precisamente lo que se necesita: un 
atributo de clase que es constante, y que no cambia de un objeto a otro de la mis- 
ma clase. Por eso, una static const de un tipo basico se puede tratar como una 
constante en tiempo de compilacion. 

Hay un caracteristica de static const cuando se usa dentro de clases que es 
un tanto inusual: se debe indicar el valor inicial en el punto en que se define. Esto 
solo ocurre con static const y no funciona en otras situaciones porque todos lo 
otros atributos deben inicializarse en el constructor o en otros metodos. 

A continuation aparece un ejemplo que muestra la creacion y uso de una static 
const llamada size en una clase que representa una pila de punteros a cadenas 5 . 

//: C08:StringStack.cpp 

// Using static const to create a 

// compile-time constant inside a class 

#include <string> 

#include <iostream> 

using namespace std; 

class StringStack { 

static const int size = 100; 
const string* stack[size]; 
int index; 

public: 

StringStack() ; 

void push (const string* s); 

const string* pop (); 


3 A1 termino de este libro, no todos los compiladores permiten esta caracteristica. 
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StringStack::StringStack() : index(O) { 

memset(stack, 0, size * sizeof (string*)) ; 

} 


void StringStack::push (const string* s) { 
if (index < size) 

stack[index++] = s; 

} 


const string* StringStack::pop() { 

if (index > 0) { 

const string* rv = stack[—index]; 
stack[index] = 0; 

return rv; 

} 

return 0; 


string iceCream[] = { 
"pralines & cream", 

"fudge ripple", 

"jamocha almond fudge", 
"wild mountain blackberry", 
"raspberry sorbet", 

"lemon swirl", 

"rocky road", 

"deep chocolate fudge" 

} ; 


const int iCsz = 

sizeof iceCream / sizeof *iceCream; 

int main () { 

StringStack ss; 
for(int i = 0; i < iCsz; i++) 
ss.push(&iceCream[i]); 
const string* cp; 
while ( (cp = ss.popO) != 0) 
cout << *cp << endl; 

} ///:- 


Como size se usa para determinar el tamano del vector stack, es adecuado 
usar una constante en tiempo de compilacion, pero que queda oculta dentro de la 
clase. 

Frjese en que push () toma un const string* como argumento, pop () retorna 
un const string* y StringStack contiene const string*. Si no fuera asi, no podria 
usar una StringStackpara contener los punteros de icecream. En cualquier caso, 
tambien impide hacer algo que cambie los objetos contenidos en StringStack. Por 
supuesto, no todos los contenedores estan disenados con esta restriction. 

El enumerado en codigo antiguo 

En versiones antiguas de C++ el tipo static const no sepermitia dentro de las 
clases. Esto hacia que const no pudiese usarse para expresiones constantes dentro 
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de clases. Pero muchos programadores lo consegulan con una solucion tlpica (nor- 
malmente conocida como «enum liack») que consiste en usar un enum sin etiqueta 
y sin instancias. Una enumeracion debe tener establecidos sus valores en tiempo de 
compilacion, es local a una clase y sus valores estan disponibles para expresiones 
constantes. Por eso, es habitual ver codigo como: 

//: CO8:EnumHack.cpp 

#include <iostream> 

using namespace std; 

class Bunch { 

enum { size = 1000 }; 
int i[size]; 

1 ; 


int main () { 

cout << "sizeof(Bunch) = " << sizeof (Bunch) 
« ", sizeof(i[1000]) = " 

<< sizeof(int [1000]) << endl; 

} ///:~ 


Este uso de enum garantiza que no se ocupa almacenamiento en el objeto, y que 
todos los slmbolos definidos en la enumeracion se evaluan en tiempo de compila¬ 
cion. Ademas se puede establecer explicitamente el valor de los slmbolos: 

enum { one = 1, two = 2, three }; 

utilizando tipos enum enteros, el compilador continuara contando a partir del 
ultimo valor, asi que el slmbolo three tendra un valor 3. 

En el ejemplo StringStack anterior, la lrnea: 

static const int size = 100; 


podria sustituirse por: 

enum { size = 100 }; 

Aunque es facil ver esta tecnica en codigo correcto, el uso de static cons- 
t fue anadido al lenguaje precisamente para resolver este problema. En todo caso, 
no existe ninguna razon abrumadora por la que deba usar static const en lugar 
de enum, y en este libro se utiliza enum porque hay mas compiladores que le dan 
soporte en el momenta en el momento en que se escribio este libro. 


8.4.3. Objetos y metodos constantes 

Las funciones miembro (metodos) se pueden hacer constantes. ^Que significa 
eso? Para entenderlo, primero debe comprender el concepto de objeto constante. 

Un objeto constante se define del mismo modo para un tipo definido por el usua- 
rio que para un tipo del lenguaje. Por ejemplo: 
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const int i = 1; 
const blob b(2); 

Aqui, b es un objeto constante de tipo blob, su constructor se llama con un 2 co- 
mo argumento. Para que el compilador imponga que el objeto sea constante, debe 
asegurar que el objeto no tiene atributos que vayan a cambiar durante el tiempo de 
vida del objeto. Puede asegurar facilmente que los atributos no publicos no sean mo- 
dificables, pero. ^Como puede saber que metodos cambiaran los atributos y cuales 
son seguros para un objeto constante? 

Si declara un metodo como constante, le esta diciendo que la funcion puede ser 
invocada por un objeto constante. Un metodo que no se declara constante se trata 
como uno que puede modificar los atributos del objeto, y el compilador no permitira 
que un objeto constante lo utilice. 

Pero la cosa no acaba ahi. Solo porque un metodo afirme ser const no garantiza 
que actuara del modo correcto, de modo que el compilador fuerza que en la defi¬ 
nicion del metodo se reitere el especificador const (la palabra const se convierte 
en parte del nombre de la funcion, asi que tanto el compilador como el enlazador 
comprobaran que no se viole la constancia). De este modo, si durante la definicion 
de la funcion se modifica algun miembro o se llama algun metodo no constante, el 
compilador emitira un mensaje de error. Por eso, esta garantizado que los miembros 
que declare const se comportaran del modo esperado. 

Para comprender la sintaxis para declarar metodos constantes, primero debe re- 
cordar que colocar const delante de la declaracion del metodo indica que el valor 
de retorno es constante, asi que no produce el efecto deseado. Lo que hay que hacer 
es colocar el especificador const despues de la lista de argumentos. Por ejemplo: 

//: C08:ConstMember.cpp 

class X { 
int i; 
public: 

X(int ii) ; 

int f() const; 

} ; 


X::X(int ii) : i (ii) {} 

int X::f() const { return i; } 

int main () { 

X xl(10) ; 
const X x2 (20) ; 
xl.f (); 
x2.f () ; 

} ///:~ 


La palabra const debe incluirse tanto en la declaracion como en la definicion del 
metodo o de otro modo el compilador asumira que es un metodo diferente. Como 
f () es un metodo constante, si intenta modificar i de alguna forma o llamar a otro 
metodo que no sea constante, el compilador informara de un error. 

Puede ver que un miembro constante puede llamarse tanto desde objetos cons¬ 
tantes como desde no constantes de forma segura. Por ello, debe saber que esa es la 
forma mas general para un metodo (a causa de esto, el hecho de que los metodos 
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no sean const por defecto resulta desafortunado). Un metodo que no modifica nin- 
gun atributo se deberia escribir como constante y asi se podria usar desde objetos 
constantes. 

Aqui se muestra un ejemplo que compara metodos const y metodos ordinarios: 

//: C08:Quoter.cpp 
// Random quote selection 
#include <iostream> 

#include <cstdlib> // Random number generator 
#include <ctime> //To seed random generator 

using namespace std; 

class Quoter { 
int lastquote; 

public: 

Quoter(); 

int lastQuoteO const; 
const char* quote(); 

} ; 


Quoter::Quoter() { 
lastquote = -1; 

srand(time(0)); // Seed random number generator 

} 


int Quoter::lastQuote () const { 
return lastquote; 

} 


const char* Quoter::quote() { 

static const char* quotes[] = { 

"Are we having fun yet?", 

"Doctors always know best", 

"Is it ... Atomic?", 

"Fear is obscene", 

"There is no scientific evidence " 

"to support the idea " 

"that life is serious", 

"Things that make us happy, make us wise", 

} ; 

const int qsize = sizeof quotes/sizeof *quotes; 
int qnum = rand() % qsize; 

while (lastquote >= 0 && qnum == lastquote) 
qnum = rand() % qsize; 
return quotes[lastquote = qnum]; 


int main() { 

Quoter q; 

const Quoter cq; 

cq.lastQuote(); //OK 

//! cq.quote(); // Not OK; non const function 

for(int i = 0; i < 20; i++) 
cout << q.quote() << endl; 

} ///:~ 
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Ni los constructores ni los destructores pueden ser metodos constantes porque 
practicamente siempre realizan alguna modification en el objeto durante la iniciali- 
zacion o la terminacion. El miembro quote () tampoco puede ser constante porque 
modifica el atributo lastquote (ver la sentencia de retorno). Por otra parte las- 
tQuote () no hace modificaciones y por eso puede ser const y puede ser llamado 
de forma segura por el objeto constante cq. 

mutable: constancia binaria vs. logica 

^Que ocurre si quiere crear un metodo constante, pero necesita cambiar algun 
atributo del objeto? Esto se aplica a veces a la diferencia entre constante binaria (bit¬ 
wise) y constante logica (llamado tambien constante memberwise). Constante binaria 
significa que todos los bits del objeto son permanentes, asi que la imagen binaria del 
objeto nunca cambia. Constante logica significa que, aunque el objeto completo es 
conceptualmente constante puede haber cambios a nivel de miembro. Si se informa 
al compilador que un objeto es constante, cuidara celosamente el objeto para asegu- 
rar constancia binaria. Para conseguir constancia logica, hay dos formas de cambiar 
los atributos con un metodo constante. 

La primera solucion es la tradicional y se llama constancia casting away. Esto se 
hace de un modo bastante raro. Se toma this (la palabra que inidica la direccion del 
objeto actual) y se moldea el puntero a un puntero a objeto de la clase actual. Parece 
que this ya es un puntero valido. Sin embargo, dentro de un metodo constante, th¬ 
is es en realidad un puntero constante, asi que moldeandolo a un puntero ordinario 
se elimina la constancia del objeto para esta operacion. Aqui hay un ejemplo: 

//: C08:Castaway.cpp 
// "Casting away" constness 

class Y { 
int i; 
public: 

Y () ; 

void f() const; 

} ; 

Y::Y () { i = 0; } 

void Y::f () const { 

//! i++; // Error — const member function 

( (Y*)this) ->i++; // OK: cast away const-ness 
// Better: use C++ explicit cast syntax: 

(const_cast<Y*>(this)) ->i++; 

} 

int main ( ) { 

const Y yy; 

yy.f(); // Actually changes it! 

} ///:- 


Esta aproximacion funciona y puede verse en codigo correcto, pero no es la tec- 
nica ideal. El problema es que esta falta de constancia esta oculta en la definicion 
de un metodo y no hay ningun indicio en la interfaz de la clase que haga sospechar 
que ese dato se modifica a menos que puede accederse al codigo fuente (buscando 
el molde). Para poner todo al descubierto se debe usar la palabra mutable en la de- 
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claracion de la clase para indicar que un atributo determinado se puede cambiar aun 
perteneciendo a un objeto constante. 

//: C08rMutable.cpp 
// The "mutable" keyword 

class Z { 
int i; 

mutable int j; 
public: 

Z 0 ; 

void f() const; 

} ; 

Z : : Z () : i (0) , j (0) {} 

void Z::f () const { 

//! i++; // Error — const member function 
j++; // OK: mutable 

} 

int main() { 

const Z zz; 

zz.f(); // Actually changes it! 

} /// : ~ 


De este modo el usuario de la clase puede ver en la declaration que miembros 
tienen posibilidad de ser modificados por un metodo. 

ROMability 

Si un objeto se define como constante es un candidato para ser almacenado en 
memoria de solo lectura (ROM), que a menudo es una consideration importante en 
programacion de sistemas empotrados. Para conseguirlo no es suficiente con que el 
objeto sea constante, los requisitos son mucha mas estrictos. Por supuesto, el objeto 
debe ser una constante binaria. Eso es facil de comprobar si la constancia logica se 
implementa mediante el uso de mutable, pero probablemente el compilador no 
podra detectarlo si se utiliza la tecnica del moldeado dentro de un metodo constante. 
Ademas: 

■ La clase o estructura no puede tener constructores o destructor definidos por 
el usuario. 

■ No pueden ser clases base (capitulo 14) u objetos miembro con constructores o 
destructor definidos por el usuario. 

El efecto de una operation de escritura en una parte del objeto constante de un 
tipo ROMable no esta definido. Aunque un objeto pueda ser colocado en ROM de 
forma conveniente, no todos lo requieren. 


8.5. Volatile 


La sintaxis de volatile es identica a la de const, pero volatile significa 
«este dato puede cambiar sin que el compilador sea informado de ello». De algun 
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modo, el entorno modifica el dato (posiblemente mediante multitarea, multihilo o 
interrupciones), y volatile indica la compilador que no haga suposiciones sobre 
el dato, especialmente durante la optimizacion. 

Si el compilador dice, «yo guarde este dato en un registro anteriormente, y no he 
tocado ese registro», normalmente no necesitara leer el dato de nuevo desde memo- 
ria. Pero si esa variable es volatile, el compilador no debe hacer esa suposicion 
porque el dato puede haber cambiado a causa de otro proceso, y debe releer el da¬ 
to en vez de optimizar el codigo (dicha optimizacion consiste en eliminar la lectura 
redundante que se hace normalmente). 

Pueden crearse objetos volatile usando la misma sintaxis que se usapara crear 
objetos constantes. Tambien puede crearse objetos volatile constantes que no pue¬ 
den cambiarse por el programador cliente pero se pueden modificar por una entidad 
ajena al programa. Aqui se muestra un ejemplo que representa una clase asociada 
con algun elemento fisico de comunicacion. 

//: C08:Volatile.cpp 
// The volatile keyword 

class Comm { 

const volatile unsigned char byte; 
volatile unsigned char flag; 
enum { bufsize = 100 }; 
unsigned char buf[bufsize]; 
int index; 
public: 

Comm (); 

void isr() volatile; 

char read (int index) const; 

} ; 


Comm::Comm() : index(O), byte(0), flag(0) {} 

// Only a demo; won't actually work 
// as an interrupt service routine: 

void Comm::isr() volatile { 

flag = 0; 

buf[index++] = byte; 

// Wrap to beginning of buffer: 
if (index >= bufsize) index = 0; 

} 


char Comm::read (int index) const { 
if (index < 0 I I index >= bufsize) 

return 0; 

return buf[index]; 


int main () { 

volatile Comm Port; 

Port.isr (); // OK 

//! Port.read(0); // Error, read() not volatile 
} ///:- 


Como ocurre con const, se puede usar volatile para los atributos de la clase. 
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los metodos y para los objetos ensi mismos. Solo puede llamar a metodos volatile 
desde objetos volatile. 

La razon por la que i s r () no se puede usar como una rutina de servicio de in- 
terrupcion (ISR) es que en un metodo, la direccion del objeto actual (this) debe pa- 
sarse secretamente, y una ISR no requiere argumentos. Para resolver este problema 
se puede hacer que el metodo isr () sea un metodo de clase (static), un asunto 
que se trata en el [FIXME:capitulo 10]. 

La sintaxis de volatile es identica a la de const, as! que por eso se suelen 
tratar juntos. Cuando se usan combinados se conocen como cuantificador c-v (const- 
volatile). 


8.6. Resumen 

La palabra const permite la posibilidad de definir objetos, argumentos de fun- 
cion, valores de retorno y metodos como constantes y elimina el uso del preprocesa- 
dor para la sustitucion de valores sin perder ninguna de sus ventajas. Todo ello ofrece 
una forma adicional de comprobacion de tipos y seguridad en la programacion. El 
uso de la llamada «constancia exacta» (const correctness) es decir, el uso de const en 
todo lugar donde sea posible, puede ser un salvavidas para muchos proyectos. 

Aunque ignore a const y continue usando el estilo tradicional de C, const exis- 
te para ayudarle. El [FIXME:capitulo 11] utiliza las referencias extensamente, y se 
vera mas sobre la importancia del uso de const en los argumentos de funciones. 

8.7. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Cree 3 valores enteros constantes, despues sumelos todos para producir un va¬ 
lor que determine el tamano en la definicion de un vector. Intente compilar el 
mismo codigo en C y vea que sucede (generalmente se puede forzar al compi- 
lador de C++ para que funcione como un compilador de C utilizando alguna 
opcion de linea de comandos). 

2. Probar que los compiladores de C y C++ realmente tratan las constantes de 
modo diferente. Cree una constante global y usela en una expresion global 
constante, compile dicho codigo en C y C++. 

3. Cree definiciones constantes para todos los tipos del lenguaje y sus variantes. 
Uselos en expresiones con otras constantes para hacer definiciones de constan¬ 
tes nuevas. Compruebe que compilan correctamente. 

4. Cree una definicion de constante en un archivo de cabecera, incluya dicho ar- 
chivo en dos archivos . cpp, compilelos y enlacelos con el compilador de C++. 
No deberian ocurrir errores. Ahora intente el mismo experimento con el com¬ 
pilador de C. 

5. Cree una constante cuyo valor se determine en tiempo de ejecucion leyendo 
la hora en que comienza la ejecucion del programa (puede usar <ctime>). 
Despues, en el programa, intente leer un segundo valor de hora, almacenarlo 
en la constante y vea que sucede. 
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6. Cree un vector de caracteres constante, despues intente cambiar uno de los 
caracteres. 

7. Cree una declaration de constante extern en un fichero y ponga un main- 
() en el que se imprima el valor de dicha constante. Cree una definition de 
constante extern en un segundo fichero, compile y enlace los dos ficheros. 

8. Defina dos punteros a const long utilizando las dos formas de definition. Apun- 
te con uno de ellos a un vector de long. Demuestre que se puede incrementar 
o decrementar el puntero, pero no se puede cambiar el valor de lo que apunta. 

9. Defina un puntero constante a double, y apunte con el a un vector de double. 
Demuestre que se puede cambiar lo que apunta el puntero pero no se puede 
incrementar ni decrementar el puntero. 

10. Defina un puntero constante a objeto constante. Pruebe que solamente se pue¬ 
de leer el valor de lo que apunta el puntero, pero no se puede cambiar el pun¬ 
tero ni lo que apunta. 

11. Elimine el comentario de la linea erronea en PointerAssignemt. cpp para 
ver que mensaje de error muestra el compilador. 

12. Cree un literal de cadena y un puntero que apunte al comienzo del literal. Aho- 
ra, use el puntero para modificar los elementos del vector, ^Inform a el compi¬ 
lador de algun error? ^Deberia? Si no lo hace, ^Porque piensa que puede ser? 

13. Cree una funcion que tome un argumento por valor como constante, despues 
intente cambiar el argumento en el cuerpo de la funcion. 

14. Cree una funcion que tome un float por valor. Dentro de la funcion vincule 
el argumento a un const float& y use dicha referencia para asegurar que el 
argumento no sea modificado 

15. Modifique ConstReturnValues . cpp eliminando los comentarios en las li- 
neas erroneas una cada vez para ver que mensajes de error muestra el compi¬ 
lador. 

16. Modifique ConsPointer . cpp eliminando los comentarios en las lineas erro¬ 
neas para ver que mensajes de error muestra el compilador. 

17. Haga una nueva version de Cons tPo inter . cpp llamada Const Reference . 
cpp que demuestre el funcionamiento con referencias en lugar de con punte¬ 
ros. (quiza necesite consultar el [FIXME:capitulo 11]). 

18. Modifique ConstTemporary. cpp eliminando el comentario en la linea erro¬ 
nea para ver el mensaje de error que muestra el compilador. 

19. Cree una clase que contenga un float constante y otro no constante. Inicialicelos 
usando la lista de initialization del constructor. 

20. Cree una clase llamada MyString que contenga una cadena y tenga un cons¬ 
tructor que inicialice la cadena y un metodo print (). Modifique StringStack. 
cpp para que maneje objetos MyString y main () para que los imprima. 

21. Cree una clase que contenga un atributo constante que se inicialice en la lista 
de initialization del constructor y una enumeration no etiquetada que se use 
para determinar el tamaho de un vector. 
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22. Elimine el especificador const en la definition del metodo de ConstMember . 
cpp, pero deje el de la declaration para ver que mensaje de error muestra el 
compilador. 

23. Cree una clase con un metodo constante y otro ordinario. Cree un objeto cons- 
tante y otro no constante de esa clase e intente invocar ambos metodos desde 
ambos objetos. 

24. Cree una clase con un metodo constante y otro ordinario. Intente llamar al 
metodo ordinario desde el metodo constante para ver que mensaje de error 
muestra el compilador. 

25. Elimine el comentario de la linea erronea en mutable . cpp para ver el mensaje 
de error que muestra el compilador. 

26. Modifique Quoter.cpp haciendo que quote () sea un metodo constante y 

lastquote sea mutable. 

27. Cree una clase con un atributo volatile. Cree metodos volatile y no vo¬ 
latile que modifiquen el atributo volatile y vea que dice el compilador. 
Cree objetos volatile y no volatile de esa clase e intente llamar a am¬ 
bos metodos para comprobar si funciona correctamente y ver que mensajes de 
error muestra el compilador en caso contrario. 

28. Cree una clase llamada bird que pueda ejecutar f ly () y una clase rock que 
no pueda. Crear un objeto rock, tome su direction y asigne a un void*. Aho- 
ra tome el void*, asignelo a un bird* (debe usar un molde) y llame a f ly () 
a traves de dicho puntero. ^Esto es posible porque la caracteristica de C que 
permite asignar a un void* (sin un molde) es un agujero del lenguaje, que no 
deberia propagarse a C++? 
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9: Funciones inline 

Una de las caracterfsticas mas importantes que C++ hereda de C es 
la eficiencia. Si la eficiencia de C++ fuese dramaticamente menor que 
la de C, podria haber un contingente significative) de programadores 
que no podrian justificar su uso. 

En C, una de las maneras de preservar la eficiencia es mediante el uso de macros, 
lo que permite hacer lo que parece una llamada a una funcion sin la sobrecarga ha¬ 
bitual de la llamada a funcion. La macro esta implementada con el preprocesador en 
vez del propio compilador, y el preprocesador reemplaza todas las llamadas a ma¬ 
cros directamente con el codigo de la macro, de manera que no hay que complicarse 
pasando argumentos, escribiendo codigo de ensamblador para CALL, retornando ar- 
gumentos ni implementando codigo ensamblador para el RETURN. Todo el trabajo lo 
realizar el preprocesador, de manera que se tiene la coherencia y legibilidad de una 
llamada a una funcion pero sin ningun coste. 

Hay dos problemas respecto al uso del preprocesador con macros en C++. La pri- 
mera tambien existe en C: una macro parece una llamada a funcion, pero no siempre 
actua como tal. Esto puede acarrear dificultades para encontrar errores. El segundo 
problema es espedfico de C++: el preprocesador no tiene permisos para acceder a la 
informacion de los miembros de una clase. Esto significa que las macros de prepro¬ 
cesador no pueden usarse como metodos de una clase. 

Para mantener la eficiencia del uso del preprocesador con macros pero anadiendo 
la seguridad y la semantica de ambito de verdaderas funciones en las clases. C++ 
tiene las funciones inline. En este capitulo veremos los problemas del uso de las 
maros de preprocesador en C++, como se resuelven estos problemas con funciones 
inline, y las directrices e incursiones en la forma en que trabajan las funciones 
inline. 


9.1. Los peligros del preprocesador 

La clave de los problemas con las macros de preprocesador radica en que puedes 
caer en el error de pensar que el comportamiento del preprocesador es igual que 
el del compilador. Por supuesto, la intencion era que una macro se parezea y actue 
como una llamada a una funcion, por eso es bastante facil caer en este error. Las 
dificultades comienzan cuando las diferencias aparecen subyacentes. 

Consideremos un ejemplo sencillo: 

#define F (x) (x + 1) 
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Ahora, si hacemos una llamada a F de esta manera: 

F (1) 

El preprocesador la expande de manera inesperada: 

(X) (X + 1) (1) 

El problema se debe al espacio entre 'F' y su parentesis de apertura en la defini¬ 
tion de la macro. Cuando el espacio es eliminado en el codigo de la macro, puedes 
llamar a la funcion incluso incluyendo el espacio. 

F (1) 

Y se expandira de manera correcta a lo siguiente: 

(1 + 1 ) 

El ejemplo anterior es un poco trivial y el problema es demasiado evidente. Las 
dificultades reales ocurren cuando se usan expresiones como argumentos en llama- 
das a macros. 

Flay dos problemas. El primero es que las expresiones pueden expandirse dentro 
de la macro de modo que la precedencia de la evaluation es diferente a lo que cabria 
esperar. Por ejemplo: 

Idefine FLOOR(x,b) x>=b?0:l 

Ahora, si usamos expresiones como argumentos: 

if (FLOOR(a&OxOf,0x07)) // ... 

La macro se expandiria a: 

if (a&0x0f>=0x07?0:1) 


La precedencia del & es menor que la del >=, de modo que la evaluation de la 
macro te sorprendera. Una vez hayas descubierto el problema, puedes solucionarlo 
insertando parentesis a todo lo que hay dentro de la definition de la macro. (Este es 
un buen metodo a seguir cuando defina macros de preprocesador), algo como: 

Idefine FLOOR(x,b) ((x)>=(b)?0:1) 

De cualquier manera, descubrir el problema puede ser dificil, y no dara con el 
hasta despues de haber dado por sentado el comportamiento de la macro en si mis- 
ma. En la version sin parentesis de la macro anterior, la mayoria de las expresiones 
van a actuar de manera correcta a causa de la precedencia de >-, que es menor que 
la mayoria de los operadores como +, /, e incluso los operadores de desplaza- 
miento. Por lo que puede pensar que funciona con todas las expresiones, incluyendo 
aquellas que empleen operadores logicos a nivel de bit. 
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El problema anterior puede solucionarse programando cuidadosamente: poner 
entre parentesis todo lo que este definido dentro de una macro. De todos modos el 
segundo problema es mas sutil. A1 contrario de una funcion normal, cada vez que 
usa argumentos en una macro, dicho argumento es evaluado. Mientras la macro sea 
llamada solo con variables corrientes, esta evaluation es benigna, pero si la evalua¬ 
tion de un argumento tiene efectos secundarios, entonces los resultados pueden ser 
inesperados y definitivamente no imitaran el comportamiento de una funcion. 

Por ejemplo, esta macro determina si un argumento entra dentro de cierto rango: 

#define BAND (x) (((x)>5 && (x)<10) ? (x) : 0) 

Mientras use un argumento «ordinario» la macro trabajara de manera bastante 
similar a una funcion real. Pero en cuanto se relaje y comience a creer que realmente 
es una funcion, comenzaran los problemas. Asl: 

//: C09 :MacroSideEffects.cpp 

#include /require.h" 

#include <fstream> 
using namespace std; 

#define BAND ( x ) ( ( (x)>5 && (x)<10) ? (x) : 0) 

int main () { 

ofstream out("macro.out"); 
assure (out, "macro.out"); 
for(int i = 4; i < 11; i++) { 

int a = i; 

out << "a = " << a << endl << '\t'; 

out << "BAND(++a)=" << BAND(++a) « endl; 

out << "\t a = " << a << endl; 

} 

} ///:- 


Observe el uso de caracteres en mayuscula en el nombre de la macro. Este es 
un buen recurso ya que advierte al lector que esto es una macro y no una funcion, 
entonces si hay algun problema, actua como recordatorio. 

A continuation se muestra la salida producida por el programa, que no es para 
nada lo que se esperarla de una autentica funcion: 


a = 4 

BAND(++a)=0 
a = 5 
a = 5 

BAND(++a)=8 
a = 8 
a = 6 

BAND(++a)=9 
a = 9 
a = 7 

BAND(++a)=10 
a = 10 
a = 8 

BAND(++a)=0 
a = 10 
a = 9 

BAND(++a)=0 
a = 11 
a = 10 

BAND(++a)=0 
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a = 12 


Cuando a es cuatro, solo ocurre la primera parte de la condicion, de modo que la 
expresion es evaluada solo una vez, y el efecto resultante de la llamada a la macro es 
que a sera 5, que es lo que se esperaria de una llamada a funcion normal en la mis- 
ma situacion. De todos modos, cuando el numero esta dentro del rango, se evaluan 
ambas condiciones, lo que da como resultado un tercer incremento. Una vez que el 
numero se sale del rango, ambas condiciones siguen siendo evaluadas de manera 
que se obtienen dos incrementos. Los efectos colaterales son distintos, dependiendo 
del argumento. 

Este no es desde luego el comportamiento que se quiere de una macro que se 
parece a una llamada a funcion. En este caso, la solucion obviamente es hacer una 
autentica funcion, lo que de hecho implica la cabecera extra y puede reducir la efi- 
ciencia si se llama demasiado a esa funcion. Desafortunadamente, el problema no 
siempre sera tan obvio, y sin saberlo. puede estar utilizando una libreria que contie- 
ne funciones y macros juntas, de modo que un problema como este puede esconder 
errores dificiles de encontrar. Por ejemplo, la macro putc () de cstdio puede lie- 
gar a evaluar dos veces su segundo argumento. Esto esta especificado en el Estandar 
C. Ademas, la implementacion descuidada de toupper () como una macro puede 
llegar a evaluar el argumento mas de una vez, lo que dara resultados inesperados 
con toupper (*p++) 1 . 


9.1.1. Macros y acceso 

Por supuesto, C requiere codificacion cuidadosa y el uso de macros de preproce- 
sador, y se podria hacer lo mismo en C++ si no fuese por un problema: las macros 
no poseen el concepto de ambito requerido con los metodos. El preprocesador sim- 
plemente hace substitucion de texto, de modo que no puede hacer algo como: 

class X{ 
int i; 

public: 

idefine VAL(X::i) // Error 

ni nada parecido. Ademas, no habria ninguna indication del objeto al que se esta 
refiriendo. Simplemente no hay ninguna forma de expresar el ambito de clase en 
una macro. No habiendo ninguna alternativa diferente a macros de preprocesador, 
los programadores se sentiran tentados de crear algunos atributos publicos por el 
bien de la eficiencia, exponiendo asi la implementacion subyacente e impidiendo 
cambios en esa implementacion, asi como eliminando la protection que proporciona 
private. 


9.2. Funciones inline 

Al resolver el problema que habia en C++ con las macros cuando acceden a miem- 
bros de clases privada, todos los problemas asociados con las macros de preprocesa¬ 
dor fueron eliminados. Esto se ha hecho aplicando el concepto de macros bajo el con¬ 
trol del compilador al cual pertenecen. C++ implementa la macro como una funcion 
inline, lo que es una funcion real en todo sentido. Todo comportamiento esperado de 


1 Andrew Koenig entra en mas detalles en su libro C Traps & Pitfalls (Addison-Wesley, 1989). 
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una funcion ordinaria se obtiene con una funcion inline. La unica diferencia es que 
una funcion inline se expande en el mismo sitio, como una macro de preprocesador, 
de modo que la cabecera de una llamada a funcion es eliminada. Por ello no deberia 
usar macros (casi) nunca, solo funciones inline. 

Cualquier funcion definida en el cuerpo de una clase es automaticamente inline, 
pero tambien puede hacer una funcion inline que no este dentro del cuerpo de una 
clase, precediendola con la palabra clave inline. De todos modos, para que esto tenga 
algun efecto, debe incluir el cuerpo de la funcion con la declaracion, de otro modo el 
compilador tratara esa funcion como una declaracion de una funcion ordinaria. Asi: 

inline int plusOne(int x); 


no tiene ningun otro efecto que declarar la funcion (que puede o no obtener una 
definicion inline despues). La aproximacion correcta proporciona el cuerpo de la fun¬ 
cion: 


inline int plusOne(int x) { return ++x; } 

Observe que el compilador revisara (como siempre lo hace), el uso apropiado 
de la lista de argumentos de la funcion y del valor de retorno (haciendo cualquier 
conversion necesaria), algo que el preprocesador es incapaz de hacer. Ademas, si 
intenta escribir lo anterior como una macro de preprocesador, obtendra un efecto no 
deseado. 

Casi siempre querra poner las funciones inline en un fichero de cabecera. Cuando 
el compilador ve una definicion como esa pone el tipo de la funcion (la firma com- 
binada con el valor de retorno) y el cuerpo de la funcion en su tabla de simbolos. 
Cuando use la funcion, el compilador se asegura de que la llamada es correcta y el 
valor de retorno se esta usando correctamente, y entonces sustituye el cuerpo de la 
funcion por la llamada a la funcion, y de ese modo elimina la sobrecarga. El codigo 
inline ocupa espacio, pero si la funcion es pequena, realmente ocupara menos es- 
pacio que el codigo generado para una llamada a funcion ordinaria (colocando los 
argumentos en la pila y ejecutando el CALL). 

Una funcion inline en un fichero de cabecera tiene un estado especial, dado que 
debe incluir el fichero de cabecera que contiene la funcion y su definicion en cada 
fichero en donde se use la funcion, pero eso no provoca un error de definicion mul¬ 
tiple (sin embargo, la definicion debe ser identica en todos los sitios en los que se 
incluya la funcion inline). 


9.2.1. inline dentro de clases 

Para definir una funcion inline, debe anteponer la palabra clave inline al nom- 
bre de la funcion en el momento de definirla. Sin embargo, eso no es necesario cuan¬ 
do se define dentro de una clase. Cualquier funcion que defina dentro de una clase 
es inline automaticamente. Por ejemplo: 

//: CO9:Inline.cpp 
// Inlines inside classes 

#include <iostream> 

#include <string> 
using namespace std; 
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class Point { 

int i , j, k ; 

public: 

Point () : 1(0), j (0) , k(0) {} 

Point (int ii, int jj, int kk) 

: i(i :), j (jj), k(kk) {} 
void print (const strings msg = "") const { 
if (msg.size() != 0) cout << msg << endl; 

cout << "i = " << i << ", " 

« "j = " « j << ", " 

<< "k = " << k << endl; 



int main () { 

Point p, q(1,2,3); 

p. print("value of p"); 

q. print("value of q"); 

} ///:- 


Aqui, los dos constructores y la funcion print () son inline por defecto. Dese 
cuenta de que usar funciones inline es transparente en main (), y asi debe ser. El 
comportamiento logico de una funcion debe ser identico aunque sea inline (de otro 
modo su compilador no funcionaria). La unica diferencia visible es el rendimiento. 

Por supuesto, la tentacion es usar declaraciones inline en cualquier parte den- 
tro de la case porque ahorran el paso extra de hacer una definicion de metodo exter¬ 
na. Sin embargo, debe tener presente, que la idea de una inline es dar al compilador 
mejores oportunidades de optimizacion. Pero, si declara inline una funcion gran¬ 
de provocara que el codigo se duplique alii donde se llame, produciendo codigo 
[FIXME:bloat] que anulara el beneficio de velocidad obtenido (la unica manera de 
descubrir los efectos del uso de inline en su programa con su compilador es experi- 
mentar). 


9.2.2. Funciones de acceso 

Uno de los usos mas importantes de inline dentro de clases son las funciones 
de acceso. Se trata de pequenas funciones que le permiten leer o cambiar parte del 
estado de un objeto, es decir, una o varias variables internas. La razon por la que 
inline es tan importante para las funciones de acceso se puede ver en el siguiente 
ejemplo: 

//: CO9:Access.cpp 
// Inline access functions 

class Access { 
int i; 
public: 

int read() const { return i; } 
void set (int ii) { i = ii; } 

} ; 


int main () { 

Access A; 

A.set (100) ; 
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int x = A.read(); 

} ///:- 


Aqul, el usuario de la clase nunca tiene contacto directo con las variables de es- 
tado internas a la clase, y pueden mantenerse como privadas, bajo el control del 
disenador de la clase. Todo el acceso a los atributos se puede controlar a traves de 
los metodos de la interfaz. Ademas, el acceso es notablemente eficiente. Conside- 
re read () , por ejemplo. Sin inline, el codigo generado para la llamada a read () 
podrla incluir colocarla en la pila y ejecutar la llamada CALL de ensamblador. En 
la mayorla de las arquitecturas, el tamano de ese codigo serla mayor que el codigo 
creado para la variante inline, y el tiempo de ejecucion serla mayor con toda certeza. 

Sin las funciones inline, un disenador de clases preocupado por la eficiencia es- 
tarla tentado de hacer que i fuese un atributo publico, eliminado la sobrecarga y 
permitiendo al usuario acceder directamente a i. Desde el punto de vista del disena¬ 
dor, eso resulta desastroso, i serla parte de la interfaz publica, lo cual significa que 
el disenador de la clase no podra cambiarlo en el futuro. Tendra que cargar con un 
entero llamado i. Esto es un problema porque despues puede que considere mejor 
usar un float en lugar de un int para representar el estado, pero como i es parte de 
la interfaz publica, no podra cambiarlo. O puede que necesite realizar algun calculo 
adicional como parte de la lectura o escritura de i, que no podra hacer si es publico. 
Si, por el contrario, siempre usa metodos para leer y cambiar la informacion de es¬ 
tado del objeto, podra modificar la representacion subyacente del objeto hasta estar 
totalmente convencido. 

Ademas, el uso de metodos para controlar atributos le permite anadir codigo al 
metodo para detectar cuando cambia el valor, algo que puede ser muy util durante 
la depuracion. Si un atributo es publico, cualquiera puede cambiarlo en cualquier 
momento sin que el programador lo sepa. 

Accesores y mutadores 

Hay gente que divide el concepto de funciones de acceso en dos: accesores (para 
leer la informacion de estado de un objeto) y mutadores (para cambiar el estado de 
un objeto). Ademas, se puede utilizar la sobrecarga de funciones para tener metodos 
accesores y mutadores con el mismo nombre; el modo en que se invoque el metodo 
determina si se lee o modifica la informacion de estado. Asl, 

//: CO9:Rectangle.cpp 
// Accessors & mutators 

class Rectangle { 
int wide, high; 

public: 

Rectangle (int w = 0, int h = 0) 

: wide(w), high(h) { } 

int width() const { return wide; } // Read 
void width (int w) { wide = w; } // Set 
int height() const { return high; } // Read 
void height (int h) { high = h; } // Set 

} ; 

int main () { 

Rectangle r(19, 47); 

// Change width & height: 
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r.height(2 * r.width()); 
r.width(2 * r.height(J); 

} ///:~ 


El constructor usa la lista de inicializacion (brevemente introducida en el capitulo 
8 y ampliamente cubierta en el capitulo 14) para asignar valores a wide y high 
(usando el formato de pseudo-constructor para los tipos de datos basicos). 

No puede definir metodos que tengan el mismo nombre que los atributos, de mo- 
do que puede que se sienta tentado de distinguirlos con un guion bajo al final. Sin 
embargo, los identificadores con guiones bajos finales estan reservados y el progra- 
mador no deberia usarlos. 

En su lugar, deberia usar «set» y «get» para indicar que los metodos son accesores 
y mutadores. 

//: CO9:Rectangle2.cpp 

// Accessors & mutators with "get" and "set" 

class Rectangle { 
int width, height; 

public: 

Rectangle (int w = 0, int h = 0) 

: width(w), height(h) {} 

int getWidthO const { return width; } 
void setwidthfint w) I width = w; } 
int getHeightO const { return height; } 
void setHeight(int h) { height = h; } 

} ; 


int main() { 

Rectangle r(19, 47); 

// Change width & height: 
r.setHeight(2 * r.getwidth()); 
r.setwidth(2 * r.getHeight() ) ; 
} ///:- 


Por supuesto, los accesores y mutadores no tienen porque ser simples tuberias 
hacia las variables internas. A veces, pueden efectuar calculos mas sofisticados. El 
siguiente ejemplo usa las funciones de tiempo de la librerla C estandar para crear 
una clase Time: 

//: CO9:Cpptime . h 
// A simple time class 

#ifndef CPPTIME_H 
#define CPPTIME_H 
#include <ctime> 

#include <cstring> 

class Time { 
std::time_t t; 
std::tm local; 
char asciiRep[26]; 

unsigned char lflag, aflag; 
void updateLocal() { 
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if (!Iflag) { 

local = *std::localtime(&t); 

Iflag++; 

} 

} 

void updateAscii() { 

if (!aflag) { 
updateLocal() ; 

std::strcpy(asciiRep,std::asctime(&local)); 
aflag++; 

} 

} 

public: 

Time() { mark(); } 

void mark() { 

lflag = aflag = 0; 
std::time(&t); 

) 

const char* ascii () { 

updateAscii(); 
return asciiRep; 

) 

// Difference in seconds: 

int delta(Time* dt) const { 

return int (std::difftime(t, dt->t)); 

} 

int daylightSavings() { 

updateLocal() ; 
return local.tm_isdst; 

} 

int dayOfYear() { // Since January 1 
updateLocal(); 
return local.tm_yday; 

} 

int dayOfWeek() { // Since Sunday 
updateLocal(); 
return local.tm_wday; 

} 

int sincel900() { // Years since 1900 
updateLocal(); 
return local.tm_year; 

) 

int month() { // Since January 

updateLocal(); 
return local.tm_mon; 

} 

int dayOfMonth() { 

updateLocal() ; 
return local.tm_mday; 

} 

int hour () { // Since midnight, 24-hour clock 

updateLocal(); 
return local.tm_hour; 

} 

int minute() { 

updateLocal() ; 
return local.tm_min; 
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int second() { 

updateLocal() ; 
return local.tm_sec; 

} 

} ; 

#endif // CPPTIME_H ///:- 


Las funciones de la libreria C estandar tienen multiples representaciones para 
el tiempo, y todas ellas son parte de la clase Time. Sin embargo, no es necesario 
actualizar todos ellos, asi que time_t se usa para la representacion base, y tm lo¬ 
cal y la representacion ASCII asciiRep tienen banderas para indicar si han sido 
actualizadas para el time_t actual. Las dos funciones privadas updateLocal () y 
updateAscii () comprueban las banderas y condicionalmente hacen la actualiza¬ 
tion. 

El constructor llama a la funcion mark () (que el usuario puede llamar tambien 
para forzar al objeto a representar el tiempo actual), y eso limpia las dos banderas 
para indicar que el tiempo local y la representacion ASCII ya no son validas. La 
funcion ascii () llama a updateAscii (), que copia el resultado de la funcion de 
la libreria estandar de C a sctime () en un buffer local porque a sctime () usa una 
area de datos estatica que se sobreescribe si la funcion se llama en otra parte. El valor 
de retorno de la funcion asci i () es la direction de ese buffer local. 

Todas las funciones que empiezan con daylightSavings () usan la funcion 
updateLocal (), que causa que la composition resultante de inlines sea bastante 
larga. No parece que valga la pena, especialmente considerando que probablemente 
no quiera llamar mucho a esas funciones. Sin embargo, eso no significa que todas las 
funciones deban ser no-inline. Si hace otras funciones no-inline, al menos mantenga 
updateLocal () como inline de modo que su codigo se duplique enlas funciones 
no-inline, eliminando la sobrecarga extra de invocation de funciones. 

Este es un pequeno programa de prueba: 

//: CO9:Cpptime.cpp 
// Testing a simple time class 

#include "Cpptime.h" 

#include <iostream> 

using namespace std; 

int main() { 

Time start; 

for(int i = 1; i < 1000; i++) { 

cout << i << ' '; 
if(i%10 == 0) cout << endl; 

} 

Time end; 
cout << endl; 

cout << "start = " << start.ascii() ; 

cout << "end = " << end.ascii(); 

cout << "delta = " << end.delta(Sstart); 

} ///:-• 


Se crea un objeto Time, se hace alguna actividad que consuma tiempo, despues 
se crea un segundo objeto Time para marcar el tiempo de finalization. Se usan para 
mostrar los tiempos de inicio, fin y los intervalos. 
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9.3. Stash y Stack con inlines 

Disponiendo de inlines, podemos modificar las clases Stash y Stack para ha- 
cerlas mas eficientes. 

//: CO9:Stash4.h 
// Inline functions 

#ifndef STASH4_H 
#define STASH4_H 

#include "../require.h" 

class Stash { 

int size; // Size of each space 

int quantity; // Number of storage spaces 
int next; // Next empty space 

// Dynamically allocated array of bytes: 

unsigned char* storage; 
void inflate(int increase); 

public: 

Stash(int sz) : size(sz), quantity(O), 
next(0), storage (0) {} 

Stash(int sz, int initQuantity) : size(sz), 
quantity(0), next(0), storage (0) { 

inflate(initQuantity) ; 

} 

Stash::-Stash() { 

if(storage != 0) 
delete []storage; 

} 

int add(void* element); 
void* fetch (int index) const { 

require(0 <= index, "Stash::fetch (-)index"); 
if(index >= next) 

return 0; //To indicate the end 
// Produce pointer to desired element: 
return &(storage[index * size]); 

} 

int count () const { return next; } 

} ; 

#endif // STASH4_H ///:- 


Obviamente las funciones pequenas funcionan bien como inlines, pero note que 
las dos funciones mas largas siguen siendo no-inline, dado que convertirlas a inline 
no representaria ninguna mejora de rendimiento. 

//: CO9:Stash4.cpp {0} 

#include "Stash4.h" 

#include <iostream> 

#include <cassert> 
using namespace std; 
const int increment = 100; 

int Stash::add (void* element) { 

if (next >= quantity) // Enough space left? 
inflate(increment); 

// Copy element into storage, 
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// starting at next empty space: 

int startBytes = next * size; 

unsigned char* e = (unsigned char* )element; 
for (int i = 0; i < size; i++) 
storage[startBytes + i] = e[i]; 
next++; 

return(next - 1); // Index number 


void Stash::inflate (int increase) { 
assert(increase >= 0); 
if (increase == 0) return; 
int newQuantity = quantity + increase; 
int newBytes = newQuantity * size; 
int oldBytes = quantity * size; 

unsigned char* b = new unsigned char [newBytes]; 
for(int i = 0; i < oldBytes; i++) 

b[i] = storage [i]; // Copy old to new 
delete [] (storage); // Release old storage 
storage = b; // Point to new memory 
quantity = newQuantity; // Adjust the size 
} ///: ~ 


Una vez mas, el programa de prueba que verifica que todo funciona correcta- 
mente. 

//: CO9:Stash4Test.cpp 
//{L} Stash4 

#include "Stash4.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

int main() { 

Stash intStash (sizeof(int) ); 
for(int i = 0; i < 100; i++) 
intStash.add(&i); 

for(int j = 0; j < intStash.count (); j++) 
cout << "intStash.fetch (" << j << ") = " 

<< * (int* )intStash.fetch ( j) 

<< endl; 

const int bufsize = 80; 

Stash stringStash (sizeof(char) * bufsize, 100); 
ifstream in("Stash4Test.cpp"); 
assure(in, "Stash4Test.cpp"); 
string line; 

while (getline(in, line)) 

stringStash.add( (char* )line.c_str()); 
int k = 0; 

char* cp; 

while((cp = (char*) stringStash.fetch(k++))!=0) 
cout << "stringStash.fetch(" << k << ") = " 

<< cp << endl; 

} ///:- 
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Este es el mismo programa de prueba que se uso antes, de modo que la salida 
deberia ser basicamente la misma. 

La clase Stack incluso hace mejor uso de inline's. 

//: CO9:Stack4.h 
// With inlines 

#ifndef STACK4_H 
#define STACK4_H 

#include "../require.h" 

class Stack { 
struct Link { 
void* data; 

Link* next; 

Link (void* dat, Link* nxt): 
data(dat), next (nxt) {} 

}* head; 

public: 

Stack() : head(0) {} 

-Stack() { 

require(head == 0, "Stack not empty"); 

) 

void push (void* dat) { 

head = new Link(dat, head); 

} 

void* peek() const { 

return head ? head->data : 0; 

} 

void* pop () { 

if (head == 0) return 0; 
void* result = head->data; 

Link* oldHead = head; 
head = head->next; 
delete oldHead; 
return result; 

} 

} ; 

#endif // STACK4_H ///:- 


Note que el destructor Link, que se presento (vacio) en la version anterior de 
Stack, ha sido eliminado. En pop (), la expresion delete oldHead simplemente 
libera la memoria usada por Link (no destruye el objeto data apuntado por el Li¬ 
nk). 

La mayoria de las funciones inline quedan bastante bien obviamente, en especial 
para Link. Incluso pop () parece justificado, aunque siempre que haya sentencias 
condicionales o variables locales no esta claro que las inlines sean beneficiosas. Aqui, 
la funcion es lo suficientemente pequena asi que es probable que no haga ningun 
dano. 

Si todas sus funciones son inline, usar la libreria se convierte en algo bastante 
simple porque el enlazado es innecesario, como puede ver en el ejemplo de prueba 
(fijese en que no hay Stack4 . cpp). 
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//: CO9:Stack4Test.cpp 
//{T} Stack4Test.cpp 

#include "Stack4.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

int main(int argc, char* argv[]) { 

requireArgs(argc, 1); // File name is argument 
ifstream in(argv[l]); 
assure(in, argv[l]); 

Stack textlines; 
string line; 

// Read file and store lines in the stack: 
while (getline(in, line)) 

textlines.push (new string(line) ) ; 

// Pop the lines from the stack and print them: 
string* s; 

while((s = (string*)textlines.pop()) != 0) { 

cout << *s << endl; 

delete s; 

} 

} ///:~ 


La gente escribe a veces clases con todas sus funciones inline, asi que la clase 
completa esta en el fichero de cabecera (vera en este libro que yo mismo lo hago). 
Durante el desarrollo de un programa probablemente esto es inofensivo, aunque 
a veces puede hacer que las compilaciones sean mas lentas. Cuando el programa 
se estabiliza un poco, probablemente querra volver a hacer las funciones no-inline 
donde sea conveniente. 


9.4. Funciones inline y el compilador 

Para comprender cuando es conveniente utilizar inlines, es util saber lo que hace 
el compilador cuando encuentra una funcion inline. Como con cualquier funcion, el 
compilador apunta el tipo de la funcion es su tabla de simbolos (es decir, el prototipo 
de la funcion incluyendo el nombre y los tipos de los argumentos, en combinacion 
con valor de retorno). Ademas cuando el compilador ve que la funcion es inline y el 
cuerpo no contiene errores, el codigo se coloca tambien en la tabla de simbolos. El co- 
digo se almacena en su forma fuente, como instrucciones ensamblador compiladas, 
o alguna otra representation propia del compilador. 

Cuando hace una llamada a una funcion inline, el compilador se asegura prime- 
ro de que la llamada se puede hacer correctamente. Es decir, los tipos de todos los 
argumentos corresponden exactamente con los tipos de la lista de argumentos de la 
funcion (o convertible a tipo correcto) y el valor de retorno tiene el tipo correcto (o 
es convertible al tipo correcto) en la expresion destino. Esto, por supuesto, es exacta¬ 
mente lo mismo que hace el compilador para cualquier funcion y hay una diferencia 
considerable respecto de lo que hace el preprocesador, porque el preprocesador no 
comprueba tipos ni hace conversiones. 
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Si toda la information del tipo de la funcion encaja en el contexto de la llama- 
da, entonces la llamada a la funcion se sustituye directamente por el codigo inline, 
eliminando la sobrecarga y permitiendo que el compilador pueda hacer mas optimi- 
zaciones. Ademas, si el inline es un metodo, la direccion del objeto(this) se pone en 
el lugar apropiado, que es, por supuesto, otra action que el preprocesador es incapaz 
de hacer. 


9.4.1. Limitaciones 

Hay dos situaciones en que el compilador no puede efectuar la sustitucion de inli¬ 
ne. En estos casos, simplemente convierte la funcion a la forma ordinaria tomando la 
definicion y pidiendo espacio para la funcion como hace con una funcion no-inline. 
Si debe hacerlo en varias unidades de traduction (lo que normalmente causaria un 
error de definicion multiple), informa al enlazador que ignore esas definiciones mul¬ 
tiples. 

En compilador no puede efectuar la sustitucion de inline si la funcion es demasia- 
do complicada. Esto depende de cada compilador particular, pero aunque muchos 
compiladores lo hagan, no habra ninguna mejora de eficiencia. En general, se consi- 
dera que cualquier tipo de bucle es demasiado complicado para expandir como una 
inline, y si lo piensa, el bucle implica mucho mas tiempo que el que conlleva la sobre¬ 
carga de la invocation de la funcion. Si la funcion es simplemente una coleccion se 
sentencias simples, probablemente el compilador no tendra ningun problema para 
utilizar inline, pero si hay muchas sentencias, la sobrecarga de llamada sera mucho 
menor que el coste de ejecutar el cuerpo. Y recuerde, cada vez que llame a una fun¬ 
cion inline grande, el cuerpo completo se inserta en el lugar de la llamada, de modo 
que el tamano del codigo se inflara facilmente sin que se perciba ninguna mejora 
de rendimiento. (Note que algunos de los ejemplos de este libro pueden exceder el 
tamano razonable para una inline a cambio de mejorar la estetica de los listados. 

El compilador tampoco efectua sustituciones inline si la direccion de la funcion 
se toma implicita o explicitamente. Si el compilador debe producir una direccion, 
entonces tendra que alojar el codigo de la funcion y usar la direccion resultante. Sin 
embargo, cuando no se requiere una direccion, probablemente el compilador hara la 
sustitucion inline. 

Es importante comprender que una declaration inline es solo una sugerencia al 
compilador; el compilador no esta forzado a hacer nada. Un buen compilador hara 
sustituciones inline para funciones pequenas y simples mientras que ignorara las 
que sean demasiado complicadas. Eso le dara lo que espera - la autentica semantica 
de una llamada a funcion con la eficiencia de una macro. 


9.4.2. Referencias adelantadas 

Si esta imaginando que el compilador [FIXME: is doing to implement inlines], 
puede confundirse pensando que hay mas limitaciones que las que existen realmen- 
te. En concreto, si una inline hace una referencia adelanta a una funcion que no ha 
sido declarada aun en la clase (sea inline o no), puede parecer que el compilador no 
sabra tratarla. 

//: CO9:EvaluationOrder.cpp 
// Inline evaluation order 

class Forward { 
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int i; 
public: 

Forward() : i(0) {} 

// Call to undeclared function: 

int f() const { return g() +1; } 

int g() const { return i; } 


int main () { 

Forward frwd; 
f rwd.f(); 

} /// : ~ 


En f (), se realiza una llamada a g (), aunque g () aun no ha sido declarada. Esto 
funciona porque la definicion del lenguaje dice que las funciones inline en una clase 
no seran evaluadas hasta la Have de cierre de la declaracion de clase. 

Por supuesto, si g () a su vez llama a f (), tendra un conjunto de llamadas re- 
cursivas, que son demasiado complicadas para el compilador pueda hacer inline. 
(Tambien, tendra que efectuar alguna comprobacion en f () o g () para forzar en 
alguna de ellas un caso base, o la recursion sera infinita). 


9.4.3. Actividades ocultas en contructores y destructores 

Constructores y destructores son dos lugares donde puede enganarse al pensar 
que una inline es mas eficiente de lo que realmente es. Constructores y destructores 
pueden tener actividades ocultas, porque la clase puede contener subobjetos cuyos 
constructores y destructores deben invocarse. Estos subobjetos pueden ser objetos 
miembro (atributos), o pueden existir por herencia (tratado en el Capitulo 14). Como 
un ejemplo de clase con un objeto miembro: 

//: CO9:Hidden.cpp 

// Hidden activities in inlines 

#include <iostream> 

using namespace std; 

class Member { 

int i , j, k; 

public: 

Member (int x = 0) : i (x) , j (x) , k (x) {} 

-Member() { cout << "-Member" << endl; } 

} ; 


class WithMembers { 

Member q, r, s; // Have constructors 

int i; 
public: 

WithMembers (int ii) : i(ii) {} // Trivial? 
-WithMembers() { 

cout << "-WithMembers" << endl; 

} 

} ; 


int main () { 

WithMembers wm(1); 
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} ///:~ 


El constructor para Member es suficientemente simple para ser inline, dado que 
no hay nada especial en el - ninguna herencia u objeto miembro esta provocando 
actividades ocultas adicionales. Pero en la clase WithMembers hay mas de lo que 
se ve a simple vista. Los constructores y destructores para los atributos q, r y s 
se llaman automaticamente, y esos constructores y destructores tambien son inline, 
asi que la diferencia es significativa respecto a metodos normales. Esto no significa 
necesariamente que los constructores y destructores deban ser no-inline; hay casos 
en que tiene sentido. Tambien, cuando se esta haciendo un prototipo inicial de un 
programa escribiendo codigo rapidamente, es conveniente a menudo usar inlines. 
Pero si esta preocupado por la eficiencia, es un sitio donde mirar. 


9.5. Reducir el desorden 

En un libro como este, la simplicidad y brevedad de poner definiciones inline 
dentro de las clases es muy util porque permite meter mas en una pagina o pantalla 
(en un seminario). Sin embargo, Dan Saks 2 ha apuntado que en un proyecto real esto 
tiene como consecuencia el desorden de la interfaz de la clase y eso hace que la clase 
sea mas incomoda de usar. El se refiere a los metodos definidos dentro de las clases 
usando la expresion in situ (en el lugar) e indica que todas las definiciones deberian 
colocarse fuera de la clase manteniendo la interfaz limpia. La optimization, argu- 
menta el, es una asunto distinto. Si se requiere optimizar, use la palabra reservada 
inline. Siguiente ese enfoque, el ejemplo anterior Rectangle . cpp quedaria: 

//: CO9:Noinsitu.cpp 
// Removing in situ functions 

class Rectangle { 
int width, height; 

public: 

Rectangle(int w = 0, int h = 0) ; 
int getwidth() const; 
void setwidth(int w); 
int getHeightO const; 
void setHeight(int h); 

}; 


inline Rectangle::Rectangle (int w, int h) 
: width(w), height(h) {} 

inline int Rectangle::getwidth() const { 
return width; 

} 


inline void Rectangle::setwidth (int w) { 
width = w; 

} 


inline int Rectangle::getHeight() const { 
return height; 

} 

2 Co-autor junto a Tom Plum de C++ Programming Guidelines, Plum Hall, 1991. 
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inline void Rectangle::setHeight (int h) { 
height = h; 

} 

int main () { 

Rectangle r(19, 47); 

// Transpose width & height: 
int iHeight = r.getHeight (); 
r.setHeight(r.getwidth()); 
r.setWidth(iHeight); 

} ///:~ 


Ahora si quiere comparar el efecto de la funciones inline con la version conven- 
cional, simplemente borre la palabra inline. (Las funciones inline normalmente 
deberian aparecen en los ficheros de cabecera, no obstante, las funciones no-inline 
deberian residir en un propia unidad de traduccion). Si quiere poner las funciones en 
la documentacion, es tan simple como un «copiar y pegar». Las funciones in situ re- 
quieren mas trabajo y tienen mas posibilidades de provocar errores. Otro argumento 
para esta propuesta es que siempre puede producir un estilo de formato consistente 
para las definiciones de funcion, algo que no siempre ocurre con las funciones in situ. 


9.6. Mas caracteristicas del preprocesador 

Antes, se dijo que casi siempre se prefiere usar funciones inline en lugar de ma¬ 
cros del preprocesador. Las excepciones aparecen cuando necesita usar tres propie- 
dades especiales del preprocesador de C (que es tambien el preprocesador de C++): 
[FIXME(hay mas):cadenizacion?] ( stringizing ), concatenacion de cadenas, y encola- 
do de simbolos ( token pasting). Stringizing, ya comentado anteriormente en el libro, 
se efectua con la directiva # y permite tomar un identificador y convertirlo en una 
cadena de caracteres. La concatenacion de cadenas tiene lugar cuando dos cadenas 
adyacentes no tienen puntuacion, en cuyo caso se combinan. Estas dos propiedades 
son especialmente utiles cuando se escribe codigo de depuracion. Asi, 

J #define DEBUG (x) cout << #x " = " << x << endl 

Esto imprime el valor de cualquier variable. Puede conseguir tambien una traza 
que imprima las sentencias tal como se ejecutan: 

j tdefine TRACE (s) cerr << #s << endl; s 

El #s cadeniza la sentencia para la salida, y la segunda s hace que la sentencia 
se ejecute. Por supuesto, este tipo de cosas pueden causar problemas, especialmente 
bucles f or de una unica linea. 

for(int i = 0; i < 100; i++) 

TRACE(f(i)); 

Como realmente hay dos sentencias en la macro TRACE () , el bucle for de una 
unica linea ejecuta solo la primera. La solucion es reemplazar el punto y coma por 
una coma en la macro. 
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9.6.1. Encolado de slmbolos 

El encolado de slmbolos, implementado con la directiva ##, es muy util cuando 
se genera codigo. Permite coger dos identificadores y pegarlos juntos para crear un 
nuevo identificador automaticamente. Por ejemplo, 

#define FIELD(a) char* a##_string; int a##_size 
class Record { 

FIELD (one) ; 

FIELD (two) ; 

FIELD(three); 

// . . . 

} ; 

Cada llamada a la macro FIELD () crea un identificador para una cadena de 
caracteres y otro para la longitud de dicha cadena. No solo es facil de leer, tambien 
puede eliminar errores de codificacion y facilitar el mantenimiento. 



9.7. Comprobacion de errores mejorada 

Las funciones de require . h se han usado antes de este punto sin haberlas de- 
finido (aunque assert () se ha usado tambien para ayudar a detectar errores del 
programador donde es apropiado). Ahora es el momento de definir este fichero de 
cabecera. Las funciones inline son convenientes aqul porque permiten colocar todo 
en el fichero de cabecera, lo que simplifica el proceso para usar el paquete. Sim- 
plemente, incluya el fichero de cabecera y se preocupe por enlazar un fichero de 
implementation. 

Deberia fijarse que las excepciones (presentadas en detalle en el Volumen 2 de 
este libro) proporcionan una forma mucho mas efectiva de manejar muchos tipos de 
errores -especialmente aquellos de los que deberia recuperarse- en lugar de simple- 
mente abortar el programa. Las condiciones que maneja require . h, sin embargo, 
son algunas que impiden que el programa continue, como por ejemplo que el usua- 
rio no introdujo suficientes argumentos en la llnea de comandos o que un fichero no 
se puede abrir. De modo que es aceptable que usen la funcion exit () de la librerla 
C estandar. 

El siguiente fichero de cabecera esta en el directorio ralz del libro, asi que es facil- 
mente accesible desde todos los capltulos. 

// : :require.h 

// From Thinking in C++, 2nd Edition 

// Available at http://www.BruceEckel.com 

// (c) Bruce Eckel 2000 

// Copyright notice in Copyright.txt 

// Test for error conditions in programs 

// Local "using namespace std" for old compilers 

#ifndef REQUIRE_H 

fdefine REQUIRE_H 

#include <cstdio> 

#include <cstdlib> 

#include <fstream> 

#include <string> 

inline void require(bool requirement. 
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const std::string& msg = "Requirement failed"){ 
using namespace std; 
if (!requirement) { 

fputs(msg.c_str() , stderr); 
fputs("\n", stderr); 
exit (1) ; 

} 


inline void requireArgs(int argc, int args, 
const std::strings msg = 

"Must use %d arguments") { 
using namespace std; 
if (argc != args + 1) { 

fprintf(stderr, msg.c_str(), args); 
fputs("\n", stderr); 
exit(1) ; 



inline void requireMinArgs(int argc, int minArgs, 
const std::strings msg = 

"Must use at least %d arguments") { 
using namespace std; 
if(argc < minArgs + 1) { 

fprintf(stderr, msg.c_str(), minArgs); 
fputs("\n", stderr); 
exit (1) ; 

} 


inline void assure(std::ifstreamS in, 
const std::stringS filename = "") { 

using namespace std; 
if(!in) { 

fprintf(stderr, "Could not open file %s\n", 
filename.c_str()) ; 
exit (1) ; 

} 


inline void assure(std::ofstreamS out, 
const std::stringS filename = "") { 

using namespace std; 
if(!out) { 

fprintf(stderr, "Could not open file %s\n", 
filename.c_str()) ; 
exit (1) ; 

} 

) 

#endif // REQUIRE_H ///:- 


Los valores por defecto proporcionan mensajes razonables que se pueden cam- 
biar si es necesario. 

Fijese en que en lugar de usar argumentos char* se utiliza const string&. Esto 
permite tanto char*, cadenas string como argumentos para estas funciones, y asi 
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es mas general (quiza quiera utilizar esta forma en su propio codigo). 

En las definiciones para requireArgs () y requireMinArgs (), se anade uno 
al numero de argumentos que necesita en la linea de comandos porque argc siempre 
incluye el nombre del programa que esta ejecutado como argumento cero, y por eso 
siempre tiene un valor que excede en uno al numero real de argumentos de la linea 
de comandos. 

Fijese en el uso de declaraciones locales using namespace std con cada fun- 
cion. Esto es porque algunos compiladores en el momenta de escribir este libro inclu- 
yen incorrectamente las funciones de la libreria C estandar en el espacio de nombres 
std, asi que la cualificacion explicita podria causar un error en tiempo de compila- 
cion. Las declaraciones locales permiten que require . h fundone tanto con librerias 
correctas como con incorrectas sin abrir el espacio de nombres std para cualquiera 
que incluya este fichero de cabecera. 

Aqui hay un programa simple para probar requite . h: 

//: CO9:ErrTest.cpp 
//{T} ErrTest.cpp 
// Testing require.h 

#include /require.h" 

#include <fstream> 
using namespace std; 

int main (int argc, char* argv[]) { 

int i = 1; 

require(i, "value must be nonzero"); 
requireArgs(argc, 1); 
requireMinArgs(argc, 1); 
ifstream in(argv[l]); 

assure (in, argv[ij); // Use the file name 
ifstream nofile("nofile.xxx"); 

// Fails: 

//! assure (nofile); // The default argument 
ofstream out("tmp.txt"); 
assure(out); 

} ///:- 


Podria estar tentado a ir un paso mas alia para manejar la apertura de ficheros y 
anadir una macro a require . h. 

#define IFOPEN(VAR, NAME) \ 
ifstream VAR(NAME); \ 
assure(VAR, NAME); 

Que podria usarse entonces asi: 

IFOPEN(in, argv[1]) 

En principio, esto podria parecer atractivo porque significa que hay que escribir 
menos. No es terriblemente inseguro, pero es un camino que es mejor evitar. Fijese 
que, de nuevo, una macro parece una funcion pero se comporta diferente; realmente 
se esta creando un objeto in cuyo alcance persiste mas alia de la macro. Quiza lo 
entienda, pero para programadores nuevos y mantenedores de codigo solo es una 
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cosa mas que ellos deben resolver. C++ es suficientemente complicado sin anadir 
confusion, asi que intente no abusar de las macros del preprocesador siempre que 
pueda. 


9.8. Resumen 

Es critico que sea capaz de ocultar la implementacion subyacente de una clase 
porque puede querer cambiarla despues. Hara estos cambios por eficiencia, o por- 
que haya alcanzado una mejor comprension del problema, o porque hay alguna clase 
nueva disponible para usar en la implementacion. Cualquier cosa que haga peligrar 
la privacidad de la implementacion subyacente reduce la flexibilidad del lenguaje. 
Por eso, la funcion inline es muy importante porque practicamente elimina la necesi- 
dad de macros de preprocesador y sus problemas asociados. Con inline, los metodos 
pueden ser tan eficientes como las macros. 

Por supuesto se puede abusan de las funciones inline en las definiciones de clase. 
El programador esta tentado de hacerlo porque es facil, asi que lo hace. Sin embargo, 
no es un problema grave porque despues, cuando se busquen reducciones de tama- 
no, siempre puede cambiar las inline a funciones convencionales dado que no afecta 
a su funcionalidad. La pauta deberia ser «Primero haz el trabajo, despues optimiza». 

9.9. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Escriba un programa que use la macro F () mostrada al principio del capitulo 
y demuestre que no se expande apropiadamente, tal como describe el texto. 
Arregle la macro y demuestre que funciona correctamente. 

2. Escriba un programa que use la macro FLOOR () mostrada al principio del ca¬ 
pitulo. Muestre las condiciones en que no funciona apropiadamente. 

3. Modifique MacroSideEf fects . cpp de modo que BAND () funcione adecua- 
damente. 

4. Cree dos funciones identicas, f 1 ( ) y f 2 (). Plaga inline a f 1 () y deje f 2- 
() como no-inline. Use la funcion clock () de la libreria C estandar que se 
encuentra en <ctime> para marcar los puntos de comienzo y fin y compare 
las dos funciones para ver cual es mas rapida. Puede que necesite hacer un 
bucle de llamadas repetidas para conseguir numeros representatives. 

5. Experimente con el tamano y complejidad del codigo de las funciones del ejer- 
cicio 4 para ver si puede encontrar el punto donde la funcion inline y la con- 
vencional tardan lo mismo. Si dispone de ellos, intentelo con compiladores dis- 
tintos y fijese en las diferencias. 

6. Pruebe que las funciones inline hacen enlazado interno por defecto. 

7. Cree una clase que contenga un array de caracteres. Anada un constructor in¬ 
line que use la funcion memset () de la libreria C estandar para inicializar el 
array al valor dado como argumento del constructor (por defecto sera ''), y un 
metodo inline llamado print () que imprima todos los caracteres del array. 
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8. Coja el ejemplo NestFriend. cpp del Capitulo 5 y reemplace todos los meto- 
dos con inline. No haga metodos inline in situ. Tambien cambie las funciones 
initialized por constructores. 

9. Modifique StringStack . cpp del Capitulo 8 para usar funciones inline. 

10. Cree un enumerado llamado Hue que contenga red, blue y yellow. Ahora cree 
una clase llama da Color que contenga un atributo de tipo Hue y un construc¬ 
tor que de valor al Hue con su argumento. Anada metodos de acceso al Hue 
get () y set (). Haga inline todos los metodos. 

11. Modifique el ejercicio 10 para usar el enfoque «accesor» y «mutador». 

12. Modifique Cpptime . cpp de modo que mida el tiempo desde que comienza el 
programa hasta que el usuario pulsa la tecla «Intro» o «Retorno». 

13. Cree una clase con dos metodos inline, el primero que esta definido en la clase 
llama al segundo, sin necesitar una declaracion adelantada. Escriba un main () 
que cree un objeto de esa clase y llame al primer metodo. 

14. Cree una clase A con un constructor por defecto inline que se anuncie a si mis- 
mo. Ahora cree una nueva clase B y ponga un objeto de A como miembro de B, 
y dele a B un constructor inline. Cree un array de objetos B y vea que sucede. 

15. Cree una gran cantidad de objetos del ejercicio anterior, y use la clase Time 
para medir las diferencias entre los contructores inline y los no-inline. (Si tiene 
un perfilador, intente usarlo tambien). 

16. Escriba un programa que tome una cadena por linea de comandos. Escriba un 
bucle for que elimine un caracter de la cadena en cada pasada, y use la macro 
DEGUB () de este capitulo para imprimir la cadena cada vez. 

17. Corrija la macro TRACE () tal como se explica en el capitulo, y pruebe que 
funciona correctamente. 

18. Modifique la macro FIELD () para que tambien incluya un indice numerico. 
Cree una clase cuyos miembros estan compuestos de llama das a la macro FIE¬ 
LD (). Anada un metodo que le permita buscar en un campo usando el indice. 
Escriba un main () para probar la clase. 

19. Modifique la macro FIELD () para que automaticamente genere funciones de 
acceso para cada campo (data deberia no obstante ser privado). Cree una clase 
cuyos miembros esten compuestos de llama das a la macro FIELD (). Escriba 
un main () para probar la clase. 

20. Escriba un programa que tome dos argumentos de linea de comandos: el pri¬ 
mero es un entero y el segundo es un nombre de fichero. Use requiere. h 
para asegurar que tiene el numero correcto de argumentos, que el entero esta 
entre 5 y 10, y que el fichero se puede abrir satisfactoriamente. 

21. Escriba un programa que use la macro IFOPEN () para abrir un fichero como 
un flujo de entrada. Fijese en la creacion un objeto if st ream y su alcance. 

22. (Desafio) Averigiie como conseguir que su compilador genere codigo ensam- 
blador. Cree un fichero que contenga una funcion muy pequena y un main (). 
Genere el codigo ensamblador cuando la funcion es inline y cuando no lo es, y 
demuestre que la version inline no tiene la sobrecarga por la llamada. 
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10: Control de nombres 

La creacion de nombres es una actividad fundamental en la pro- 
gramacion, y cuando un proyecto empieza a crecer, el numero de 
nombres puede llegar a ser inmanejable con facilidad. 

C++ permite gran control sobre la creacion y visibilidad de nombres, el lugar 
donde se almacenan y el enlazado de nombres. La palabra clave static estaba so- 
brecargada en C incluso antes de que la mayorla de la gente supiera que significaba 
el termino «sobrecargar». C++ ha anadido ademas otro significado. El concepto sub- 
yacente bajo todos los usos de static parece ser «algo que mantiene su posicion» 
(como la electricidad estatica), sea manteniendo un ubicacion flsica en la memoria o 
su visibilidad en un fichero. 

En este capitulo aprendera como static controla el almacenamiento y la visi¬ 
bilidad, asi como una forma mejorada para controlar los nombres mediante el uso 
de la palabra clave de C++ namespace. Tambien descubrira como utilizar funciones 
que fueron escritas y compiladas en C. 


10.1. Los elementos estaticos de C 

Tanto en C como en C++ la palabra clave static tiene dos significados basicos 
que, desafortunadamente, a menudo se confunden: 

■ Almacenado una sola vez en una direccion de memoria fija. Es decir, el objeto 
se crea en una area de datos estatica especial en lugar de en la pila cada vez 
que se llama a una funcion. Este es el concepto de almacenamiento estatico. 

■ Local a una unidad de traduccion particular (y tambien local para el ambito de 
una clase en C++, tal como se vera despues). Aqui, static controla la visibi¬ 
lidad de un nombre, de forma que dicho nombre no puede ser visto fuera del 
la unidad de traduccion o la clase. Esto tambien corresponde al concepto de 
enlazado, que determina que nombres vera el enlazador. 

En esta seccion se van a analizar los significados anteriores de static tal y como 
se heredaron de C. 


10.1.1. Variables estaticas dentro de funciones 

Cuando se crea una variable local dentro de una funcion, el compilador reserva 
espacio para esa variable cada vez que se llama a la funcion moviendo hacia abajo el 
puntero de pila tanto como sea preciso. Si existe un inicializador para la variable, la 
inicializacion se realiza cada vez que se pasa por ese punto de la secuencia. 
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No obstante, a veces es deseable retener un valor entre llamadas a funcion. Esto 
se puede lograr creando una variable global, pero entonces esta variable no estara 
unicamente bajo control de la funcion. C y C++ permiten crear un objeto stati- 
c dentro de una funcion. El almacenamiento de este objeto no se lleva a cabo en la 
pila sino en el area de datos estaticos del programa. Dicho objeto solo se inicializa 
una vez, la primera vez que se llama a la funcion, y retiene su valor entre diferentes 
invocaciones. Por ejemplo, la siguiente funcion devuelve el siguiente caracter del 
vector cada vez que se la llama: 

//: CIO:StaticVariablesInfunctions.cpp 

#include /require.h" 

#include <iostream> 

using namespace std; 

char oneChar (const char* charArray =0) { 

static const char* s; 

if (charArray) { 
s = charArray; 

return * s; 

} 

else 

require(s, "un-initialized s"); 
if (*s == '\0') 

return 0; 
return *s++; 


char* a = "abcdefghijklmnopqrstuvwxyz"; 
int main () { 

// oneChar(); // require () fails 
oneChar(a); // Initializes s to a 

char c; 

while ((c = oneChar()) != 0) 

cout << c << endl; 

} ///:~ 


La variable static char* s mantiene su valor entre llamadas a oneChar () porque 
no esta almacenada en el segmento de pila de la funcion, sino que esta en el area 
de almacenamiento estatico del programa. Cuando se llama a oneChar () con char* 
como argumento, s se asigna a ese argumento de forma que se devuelve el primer 
caracter del array. Cada llamada posterior a oneChar () sin argumentos devuelve el 
valor por defecto cero para charArray, que indica a la funcion que todavia se es- 
tan extrayendo caracteres del valor previo de s. La funcion continuara devolviendo 
caracteres hasta que alcance el valor de final del vector, momento en el que para de 
incrementar el puntero evitando que este sobrepase la ultima posicion del vector. 

Pero <i,que pasa si se llama a oneChar () sin argumentos y sin haber inicializa- 
do previamente el valor de s? En la definicion para s, se podia haber utilizado la 
inicializacion, 

static char* s = 0; 


pero si no se incluye un valor inicial para una variable estatica de un tipo defini- 



'Volumenl" — 2012/1/12 — 13:52 — page 277 — #315 


10.1. Los elementos estaticos de C 


do, el compilador garantiza que la variable se inicializara a cero (convertido al tipo 
adecuado) al comenzar el programa. Asi pues, en oneChar (), la primera vez que 
se llama a la funcion, s vale cero. En este caso, se cumplira la condition i f ( ! s). 

La inicializacion anterior para s es muy simple, pero la inicializacion para objetos 
estaticos (como la de cualquier otro objeto) puede ser una expresion arbitraria, que 
involucre constantes, variables o funciones previamente declaradas. 

Fijese que la funcion de arriba es muy vulnerable a problemas de concurren- 
cia. Siempre que disene funciones que contengan variables estaticas, debera tener en 
mente este tipo de problemas. 

Objetos estaticos dentro de funciones 

Las reglas son las mismas para objetos estaticos de tipos definidos por el usuario, 
anadiendo el hecho que el objeto requiere ser inicializado. Sin embargo, la asignacion 
del valor cero solo tiene sentido para tipos predefinidos. Los tipos definidos por el 
usuario deben ser inicializados llamando a sus respectivos constructores. Por tanto, 
si no especifica argumentos en los constructores cuando defina un objeto estatico, la 
clase debera tener un constructor por defecto. Por ejemplo: 

//: CIO:StaticObjectsInFunctions.cpp 

#include <iostream> 

using namespace std; 

class X { 
int i; 
public: 

X(int ii = 0) : i(ii) {} // Default 

~X() { cout « "X :: ~X ()" << endl; } 

} ; 

void f() { 

static X xl(47); 

static X x2; // Default constructor required 

} 

int main() { 

f 0 ; 

} ///:~ 


Los objetos estaticos de tipo X dentro de f () pueden ser inicializados tanto con la 
lista de argumentos del constructor como con el constructor por defecto. Esta cons¬ 
truction ocurre unicamente la primera vez que el control llega a la definition. 

Destructores de objetos estaticos 

Los destructores para objetos estaticos (es decir, cualquier objeto con almacena- 
miento estatico, no solo objetos estaticos locales como en el ejemplo anterior) son 
invocados cuando main () finaliza o cuando la funcion de libreria estandar de C 
exit () se llama explicitamente. En la mayoria de implementaciones, main () sim- 
plemente llama a exit () cuando termina. Esto significa que puede ser peligroso 
llamar a exit () dentro de un destructor porque podria producirse una invocation 
recursiva infinita. Los destructores de objetos estaticos no se invocan si se sale del 
programa utilizando la funcion de libreria estandar de C abort (). 
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Es posible especificar acciones que se lleven a cabo tras finalizar la ejecucion de 
main () (o llamando a exit ()) utilizando la funcion de libreria estandar de C at- 
exit ( ). En este caso, las funciones registradas en atexit () seran invocadas antes 
de los destructores para cualquier objeto construido antes de abandonar main () (o 
de llamar a exit () ). 

Como la destruccion ordinaria, la destruccion de objetos estaticos se lleva a cabo 
en orden inverso al de la inicializacion. Hay que tener en cuenta que solo los objetos 
que han sido construidos seran destruidos. Afortunadamente, las herramientas de 
desarrollo de C++ mantienen un registro del orden de inicializacion y de los objetos 
que han sido construidos. Los objetos globales siempre se construyen antes de entrar 
en main () y se destruyen una vez se sale, pero si existe una funcion que contiene 
un objeto local estatico a la que nunca se llama, el constructor de dicho objeto nunca 
fue ejecutado y, por tanto, nunca se invocara su destructor. Por ejemplo: 

//: CIO:StaticDestructors.cpp 
// Static object destructors 

#include <fstream> 
using namespace std; 

ofstream out("statdest>out"); // Trace file 

class Obj { 

char c; // Identifier 

public: 

Obj (char cc) : c(cc) { 

out << "0bj::0bj() for " << c << endl; 

} 

~0bj() { 

out << "Obj::~Obj() for " << c << endl; 


} ; 


Obj a('a'); // Global (static storage) 

// Constructor & destructor always called 

void f() { 

static Obj b('b'); 

} 


void g() { 

static Obj c(' c '); 

} 

int main () { 

out << "inside main()" << endl; 

f(); // Calls static constructor for b 

// g () not called 

out << "leaving main()" << endl; 

} ///:- 


En Obj, char c actua como un identificador de forma que el constructor y el 
destructor pueden imprimir la informacion acerca del objeto sobre el que actuan. 0- 
b j a es un objeto global y por tanto su constructor siempre se llama antes de que el 
control pase a main (), pero el constructor para static Obj b dentro de f (), y el 
de static Obj c dentro de g () solo seran invocados si se llama a esas funciones. 
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Para mostrar que constructores y que destructores seran llamados, solo se invoca 
a f (). La salida del programa sera la siguiente: 


Obj::Obj() for a 
inside main() 

Obj::Obj() for b 
leaving main() 
Obj::~Obj() for b 
Obj::~Obj() for a 


El constructor para a se invoca antes de entrar en main () y el constructor de b se 
invoca solo porque existe una llama da a f (). Cuando se sale de main () , se invoca 
a los destructores de los objetos que han sido construidos en orden inverso al de su 
construction. Esto significa que si llama a g (), el orden en el que los destructores 
para bye son invocados depende de si se llamo primero a f () o a g (). 

Notese que el objeto out de tipo of stream, utilizado en la gestion de ficheros, 
tambien es un objeto estatico (puesto que esta definido fuera de cualquier funcion, 
reside en el area de almacenamiento estatico). Es importante remarcar que su defini¬ 
tion (a diferencia de una declaration tipo extern) aparece al principio del fichero, 
antes de cualquier posible uso de out. De lo contrario estariamos utilizando un ob¬ 
jeto antes de que estuviese adecuadamente inicializado. 

En C++, el constructor de un objeto estatico global se invoca antes de entrar en 
main (), de forma que ya dispone de una forma simple y portable de ejecutar codigo 
antes de entrar en main (), asi como ejecutar codigo despues de salir de main (). En 
C, eso siempre implicaba revolver el codigo ensamblador de arranque del compila- 
dor utilizado. 


10.1.2. Control del enlazado 

Generalmente, cualquier nombre dentro del ambito del fichero (es decir, no in- 
cluido dentro de una clase o de una funcion) es visible para todas las unidades de 
traduction del programa. Esto suele llamarse enlazado externo porque durante el 
enlazado ese nombre es visible desde cualquier sitio, desde el exterior de esa uni- 
dad de traduction. Las variables globales y las funciones ordinarias tienen enlazado 
externo. 

Hay veces en las que conviene limitar la visibilidad de un nombre. Puede que 
desee tener una variable con visibilidad a nivel de fichero de forma que todas las 
funciones de ese fichero puedan utilizarla, pero quiza no desee que funciones ex- 
ternas a ese fichero tengan acceso a esa variable, o que de forma inadvertida, cause 
solapes de nombres con identificadores externos a ese fichero. 

Un objeto o nombre de funcion, con visibilidad dentro del fichero en que se en- 
cuentra, que es explicitamente declarado como static es local a su unidad de tra¬ 
duction (en terminos de este libro, el fichero epp donde se lleva a cabo la declara¬ 
tion). Este nombre tiene enlace interno. Esto significa que puede usar el mismo nom¬ 
bre en otras unidades de traduction sin confusion entre ellos. 

Una ventaja del enlace interno es que el nombre puede situarse en un fichero de 
cabecera sin tener que preocuparse de si habra o no un choque de nombres durante el 
enlazado. Los nombres que aparecen usualmente en los archivos de cabecera, como 
definiciones const y funciones inline, tienen por defecto enlazado interno. (De 
todas formas, const tiene por defecto enlazado interno solo en C++; en C tiene 
enlazado externo). Notese que el enlazado se refiere solo a elementos que tienen 
direcciones en tiempo de enlazado / carga. Por tanto, las declaraciones de clases y 




0 


0 


0 


"Volumenl" — 2012/1/12 — 13:52 — page 280 — #318 


0 


Capitulo 10. Control de nombres 


de variables locales no tienen enlazado. 

Confusion 

He aqui un ejemplo de como los dos significados de st at i c pueden confundirse. 
Todos los objetos globales tienen implicitamente almacenamiento de tipo estatico, o 
sea que si usted dice (en ambito de fichero) 

int a = 0; 

el almacenamiento para a se llevara a cabo en el area para datos estaticos del 
programa y la inicializacion para a solo se realizara una vez, antes de entrar en ma¬ 
in (). Ademas, la visibilidad de a es global para todas las unidades de traduccion. 
En terminos de visibilidad, lo opuesto a static (visible tan solo en su :unidad de 
traduccion) es extern que establece explicitamente que la visibilidad del nombre se 
extienda a todas las unidades de traduccion. Es decir, la definicion de arriba equivale 
a 


extern int a = 0; 

Pero si utilizase 

static int a = 0; 

todo lo que habria hecho es cambiar la visibilidad, de forma que a tiene enlace 
interno. El tipo de almacenamiento no se altera, el objeto reside en el area de datos 
estatica aunque en este caso su visibilidad es static y en el otro es extern. 

Cuando pasamos a hablar de variables locales, static deja de alterar la visibili¬ 
dad y pasa a alterar el tipo de almacenamiento. 

Si declara lo que parece ser una variable local como extern, significa que el 
almacenamiento existe en alguna otra parte (y por tanto la variable realmente es 
global a la funcion). Por ejemplo: 

//: CIO:LocalExtern.cpp 
//{L} LocalExtern2 
#include <iostream> 

int main)) { 
extern int i; 

std::cout << i; 

} ///:~ 


Para nombres de funciones (sin tener en cuenta las funciones miembro), static 
y extern solo pueden alterar la visibilidad, de forma que si escribe 

j extern void f() ; 

es lo mismo que la menos adornada declaration 

j void f() ; 
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y si utiliza 

static void f(); 

significa que f () es visible solo para la unidad de traduccion, (esto suele llamarse 
estdtico afichero (file static). 


10.1.3. Otros especificadores para almacenamiento de cla- 
ses 

El uso de static y extern esta muy extendido. Existen otros dos especifica¬ 
dores de tipo de almacenamiento bastante menos conocidos. El especificador auto 
no se utiliza practicamente nunca porque le dice al compilador que esa es una varia¬ 
ble local, auto es la abreviatura de automatico«» y se refiere a la forma en la que el 
compilador reserva espacio automaticamente para la variable. El compilador siem- 
pre puede determinar ese hecho por el contexto en que la variable se define por lo 
que aut o es redundante. 

El especificador register aplicado a una variable indica que es una variable 
local (auto), junto con la pista para el compilador de que esa variable en concreto va 
a ser ampliamente utilizada por lo que deberia ser almacenada en un registro si es 
posible. Por tanto, es una ayuda para la optimizacion. Diferentes compiladores res- 
ponden de diferente manera ante dicha pista; incluso tienen la opcion de ignorarla. 
Si toma la direccion de la variable, el especificador register va a ser ignorado casi 
con total seguridad. Se recomienda evitar el uso de register porque, generalmen- 
te, el compilador suele realizar las labores de optimizacion mejor que el usuario. 


10.2. Espacios de nombres 

Pese a que los nombres pueden estar anidados dentro de clases, los nombres de 
funciones globales, variables globales y clases se encuentran incluidos dentro de un 
unico espacio de nombres. La palabra reserva da static le da control sobre este per- 
mitiendole darle tanto a variables como a funciones enlazado inferno (es decir con- 
virtiendolas en estaticas al fichero). Pero en un proyecto grande, la falta de control 
sobre el espacio de nombres global puede causar problemas. Con el fin de solventar 
esos problemas para clases, los programadores suelen crear nombres largos y com- 
plicados que tienen baja probabilidad de crear conflictos pero que suponen hartarse 
a teclear para escribirlos. (Para simplificar este problema se suele utilizar typedef). 
Pese a que el lenguaje la soporta, no es una solucion elegante. 

En lugar de eso puede subdividir el espacio de nombres global en varias par¬ 
tes mas manejables utilizando la caracteristica namespace de C++. La palabra re- 
servada namespace, de forma similar a class, struct, enum y union, situa los 
nombres de sus miembros en un espacio diferente. Mientras que las demas palabras 
reservadas tienen propositos adicionales, la unica funcion de namespace es la de 
crear un nuevo espacio de nombres. 


10.2.1. Crear un espacio de nombres 

La creacion de un espacio de nombres es muy similar a la creacion de una clase: 
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//: CIO:MyLib.cpp 

namespace MyLib { 

// Declarations 

} 

int raain() {} ///:- 


Ese codigo crea un nuevo espacio de nombres que contiene las declaraciones in- 
cluidas entre las llaves. De todas formas, existen diferencias significativas entre cl¬ 
ass, struct, enum y union: 

■ Una definicion con namespace solamente puede aparecer en un rango global 
de visibilidad o anidado dentro de otro namespace. 

■ No es necesario un punto y coma tras la Have de cierre para finalizar la defini¬ 
cion de namespace. 

■ Una definicion namespace puede ser "continuada" en multiples archivos de 
cabecera utilizando una sintaxis que, para una clase, pareceria ser la de una 
redefinition: 


//: CIO:Headerl.h 

#ifndef HEADER1_H 
#define HEADER1_H 
namespace MyLib { 
extern int x; 
void f(); 

// . . . 

} 


#endif // HEADER1_H ///:- 


El posible crear alias de un namespace de forma que no hace falta que teclee un 
enrevesado nombre creado por algun frabricante de librerias: 

//: CIO:BobsSuperDuperLibrary.cpp 

namespace BobsSuperDuperLibrary { 
class Widget { /* ... */ }; 
class Poppit { /* ... */ }; 

II... 

} 

// Too much to type! I'll alias it: 
namespace Bob = BobsSuperDuperLibrary; 
int main)) {} ///:- 


No puede crear una instancia de un namespace tal y como puede hacer con una 
clase. 

Espacios de nombres sin nombre 

Cada unidad de traduction contiene un espacio de nombres sin nombre al que 
puede referirse escribiendo «namespace» sin ningun identificador. 



'Volumenl" — 2012/1/12 — 13:52 — page 283 — #321 


10.2. Espacios de nombres 


Los nombres en este espacio estan disponibles automaticamente en esa unidad 
de traduccion sin cualificacion. Se garantiza que un espacio sin nombre es unico 
para cada unidad de traduccion. Si usted asigna nombres locales en un espacio de 
nombres no necesitara darles enlazado interno con static. 

En C++ es preferible utilizar espacios de nombres sin nombre que estdticos afiche- 
ro. 

Amigas 

Es posible anadir una declaration tipo friend dentro de un espacio de nombres 
incluyendola dentro de una clase: 

//: CIO:Friendlnjection.cpp 

namespace Me { 
class Us { 

friend void you (); 


int main () {} ///:- 


Ahora la funcion you () es un miembro del espacio de nombres Me. 

Si introduce una declaration tipo friend en una clase dentro del espacio de 
nombres global, dicha declaration se inyecta globalmente. 


10.2.2. Como usar un espacio de nombres 

Puede referirse a un nombre dentro de un espacio de nombres de tres maneras 
diferentes: especificando el nombre utilizando el operador de resolution de ambito, 
con una directiva using que introduzca todos los nombres en el espacio de nombres 
o mediante una declaration using para introducir nombres de uno en uno. 

Resolution del ambito 

Cualquier nombre en un espacio de nombres puede ser explicitamente especifi- 
cado utilizando el operador de resolution de ambito de la misma forma que puede 
referirse a los nombres dentro de una clase: 

//: CIO:ScopeResolution.cpp 

namespace X { 
class Y { 

static int i; 
public: 
void f(); 

} ; 

class Z; 
void func (); 

} 

int X : : Y: : i = 9; 

class X::Z { 
int u, v, w; 
public: 

Z(int i); 
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int g(); 

} ; 

X::Z::Z(int i) {u=v=w=i; } 

int X::Z::g() { return u = v = w = 0; } 

void X:: func() { 

X: : Z a (1) ; 
a.g() ; 

} 

int main(){} ///:- 


Notese que la definicion X: : Y: : i puede referirse tambien a un atributo de la 
clase Y anidada dentro de la clase X en lugar del espacio de nombres X. 

La directiva using 

Puesto que teclear toda la especificacion para un identificador en un espacio de 
nombres puede resultar rapidamente tedioso, la palabra clave using le permite im- 
portar un espacio de nombres entero de una vez. Cuando se utiliza en conjuncion 
con la palabra clave namespace, se dice que utilizamos una directiva using. Las 
directivas using hacen que los nombres actuen como si perteneciesen al ambito del 
espacio de nombres que les incluye mas cercano por lo que puede utilizar conve- 
nientemente los nombres sin explicitar completamente su especificacion. Considere 
el siguiente espacio de nombres: 

//: CIO:Namespacelnt.h 

#ifndef NAMESPACEINT_H 
#define NAMESPACEINT_H 

namespace Int { 

enum sign { positive, negative }; 
class Integer { 
int i ; 

sign s; 

public: 

Integer (int ii = 0) 

: i(ii), 

s(i >= 0 ? positive : negative) 

{} 

sign getSign() const { return s; } 
void setSign(sign sgn) { s = sgn; } 


} ; 


#endif // NAMESPACEINT_H ///:- 


Un uso de las directivas using es incluir todos los nombres en Int dentro de 
otro espacio de nombres, dejando aquellos nombres anidados dentro del espacio de 
nombres 

//: CIO :NamespaceMath.h 

#ifndef NAMESPACEMATH_H 
#define NAME S PAC EMAT H_H 
#include "Namespacelnt.h" 
namespace Math { 

using namespace Int; 
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Integer a, b; 

Integer divide(Integer, Integer); 

II... 

) 

#endif // NAMESPACEMATH_H ///:- 


Tambien puede declarar todos los nombres en Int dentro de la funcion pero 
dejando esos nombres anidados dentro de la funcion: 

//: CIO:Arithmetic.cpp 

#include "Namespacelnt.h" 
void arithmetic() { 

using namespace Int; 

Integer x; 

x.setSign(positive); 

} 

int main(){} ///:- 


Sin la directiva using, todos los nombres en el espacio de nombres requeririan 
estar completamente explicitados. 

Hay un aspecto de la directiva using que podria parecer poco intuitivo al princi- 
pio. La visibilidad de los nombres introducidos con una directiva using es el rango 
en el que se crea la directiva. Pero jpuede hacer caso omiso de los nombres definidos 
en la directiva using como si estos hubiesen sido declarados globalmente para ese 
ambito! 

//: CIO:NamespaceOverridingl.cpp 

#include "NamespaceMath.h" 
int main() { 

using namespace Math; 

Integer a; // Hides Math::a; 
a . setSign(negative); 

// Now scope resolution is necessary 
// to select Math::a : 

Math::a.setSign(positive) ; 

} ///:- 


Suponga que tiene un segundo espacio de nombres que contiene algunos nom¬ 
bres en namespace Math: 

//: CIO:NamespaceOverriding2.h 

#ifndef NAMESPACEOVERRIDING2_H 
#define NAMESPACEOVERRIDING2_H 
#include "Namespacelnt.h" 
namespace Calculation { 

using namespace Int; 

Integer divide(Integer, Integer); 



#endif // NAMESPACEOVERRIDING2_H ///:- 
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Dado que este espacio de nombres tambien se introduce con una directiva u- 
sing, existe la posibilidad de tener una colision. De todos modos, la ambigiiedad 
aparece en el momento de utilizar el nombre, no en la directiva using: 

//: CIO:OverridingAmbiguity.cpp 

#include "NamespaceMath.h" 

#include "NamespaceOverriding2.h" 

void s() { 

using namespace Math; 
using namespace Calculation; 

// Everything's ok until: 

//! divide(1, 2); // Ambiguity 

} 

int main)) {} ///:- 


Por tanto, es posible escribir directivas using para introducir un numero de es- 
pacios de nombre con nombres conflictivos sin producir ninguna ambigiiedad. 

La declaration using 

Puede inyectar nombres de uno en uno en el ambito actual utilizando una de¬ 
claracion using. A diferencia de la directiva using, que trata los nombres como 
si hubiesen sido declarados globalmente para ese ambito, una declaracion usin- 
g es una declaracion dentro del ambito actual. Eso significa que puede sobrescribir 
nombres de una directiva using: 

//: CIO:UsingDeclaration.h 

#ifndef USINGDECLARATION_H 
#define USINGDECLARATION_H 

namespace U { 

inline void f() {} 

inline void g() {} 

} 

namespace V { 

inline void f() {} 

inline void g() {} 

} 

#endif // USINGDECLARATION_H ///:- 


La declaracion using simplemente da el nombre completamente especificado 
del identificador pero no da informacion de tipo. Eso significa que si el espacio de 
nombres contiene un grupo de funciones sobrecargadas con el mismo nombre, la 
declaracion using declara todas las funciones pertenecientes al grupo sobrecargado. 

Es posible poner una declaracion using en cualquier sitio donde podria ponerse 
una declaracion normal. Una declaracion using funciona de la misma forma que 
cualquier declaracion normal salvo por un aspecto: puesto que no se le da ninguna 
lista de argumentos, una declaracion using puede provocar la sobrecarga de una 
funcion con los mismos tipos de argumentos (cosa que no esta permitida por el pro- 
cedimiento de sobrecarga normal). De todas formas, esta ambigiiedad no se muestra 
hasta el momento de uso, no apareciendo en el instante de declaracion. 

Una declaracion using puede tambien aparecer dentro de un espacio de nom¬ 
bres y tiene el mismo efecto que en cualquier otro lugar (ese nombre se declara dentro 
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del espacio): 

//: CIO:UsingDeclaration2.cpp 

#include "UsingDeclaration.h" 

namespace Q { 
using U::f; 
using V::g; 

// ... 

} 

void m() { 

using namespace Q; 

f (); // Calls U: : f() ; 
g () ; // Calls V: :g () ; 

} 

int main () {} ///:- 


Una declaration using es un alias. Le permite declarar la misma funcion en es- 
pacios de nombres diferentes. Si acaba redeclarando la misma funcion importando 
diferentes espacios de nombres no hay problema, no habra ambigiiedades o dupli- 
cados. 


10.2.3. El uso de los espacios de nombres 

Algunas de las reglas de arriba pueden parecer un poco desalentadoras al prin- 
cipio, especialmente si tiene la impresion que las utilizara constantemente. No obs¬ 
tante, en general es posible salir airoso con el uso de espacios de nombres facilmente 
siempre y cuando comprenda como funcionan. La clave a recordar es que cuando in¬ 
troduce una directiva using global (via "using namespace" fuera de cualquier ran- 
go) usted ha abierto el espacio de nombres para ese archivo. Esto suele estar bien 
para un archivo de implementation (un archivo "cpp") porque la directiva using 
solo afecta hasta el final de la compilation de dicho archivo. Es decir, no afecta a nin- 
gun otro archivo, de forma que puede ajustar el control de los espacios de nombres 
archivo por archivo. Por ejemplo, si usted descubre un cruce de nombres debido a 
que hay demasiadas directivas using en un archivo de implementation particular, 
es una cuestion simple cambiar dicho archivo para que use calificaciones explicitas 
o declaraciones using para eliminar el cruce sin tener que modificar ningun otro 
archivo de implementation. 

Los ficheros de cabecera ya son otra historia. Practicamente nunca querra intro- 
ducir una directiva using global en un fichero de cabecera, puesto que eso signifi- 
caria que cualquier otro archivo que incluyese la cabecera tambien tendria el espacio 
de nombres desplegado (y un fichero de cabecera puede incluir otros ficheros de 
cabecera). 

Por tanto, en los ficheros de cabecera deberia utilizar o bien cualificacion explicita 
o bien directivas using de ambito y declaraciones using. Este es el metodo que 
encontrara en este libro. Siguiendo esta metodologia no «contaminara» el espacio de 
nombres global, que implicaria volver al mundo pre-espacios de nombres de C++. 


10.3. Miembros estaticos en C++ 


A veces se necesita un unico espacio de almacenamiento para utilizado por todos 
los objetos de una clase. En C, podria usar una variable global pero eso no es muy 
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seguro. Los datos globales pueden ser modificados por todo el mundo y su nombre 
puede chocar con otros identicos si es un proyecto grande. Seria ideal si los datos 
pudiesen almacenarse como si fuesen globales pero ocultos dentro de una clase y 
claramente asociados con esa clase. 

Esto esposible usando atributos static. Existe una unicaporcion deespaciopa¬ 
ra los atributos static, independientemente del numero de objetos de dicha clase 
que se hayan creado. Todos los objetos comparten el mismo espacio de almacena- 
miento static para ese atributo, constituyendo una forma de «comunicarse» entre 
ellos. Pero los datos static pertenecen a la clase; su nombre esta restringido al in¬ 
terior de la clase y puede ser public, private o protected. 



10.3.1. Definition del almacenamiento para atributos esta- 
ticos 

Puesto que los datos static tienen una unica porcion de memoria donde alma¬ 
cenarse, independientemente del numero de objetos creados, esa porcion debe ser 
definida en un unico sitio. El compilador no reservara espacio de almacenamiento 
por usted. El enlazador reportara un error si un atributo miembro es declarado pero 
no definido. 

La definicion debe realizarse fuera de la clase (no se permite el uso de la sentencia 
inline), y solo esta permitida una definicion. Es por ello que habitualmente se in- 
cluye en el fichero de implementation de la clase. La sintaxis suele traer problemas, 
pero en realidad es bastante logica. Por ejemplo, si crea un atributo estatico dentro 
de una clase de la siguiente forma: 

class A { 

static int 1; 
public: 

II... 

} ; 

Debera definir el almacenamiento para ese atributo estatico en el fichero de defi¬ 
nicion de la siguiente manera: 

int A::i = 1; 

Si quisiera definir una variable global ordinaria, deberia utilizar 

int i = 1; 

pero aqui, el operador de resolution de ambito y el nombre de la clase se utilizan 
para especificar A : : i. 

Algunas personas tienen problemas con la idea que A: : i es private, y pese 
a ello parece haber algo que lo esta manipulando abiertamente. ^No rompe esto el 
mecanismo de protection? Esta es una practica completamente segura por dos ra- 
zones. Primera, el unico sitio donde esta initialization es legal es en la definicion. 
Efectivamente, si el dato static fuese un objeto con un constructor, habria llamado 
al constructor en lugar de utilizar el operador =. Segundo, una vez se ha realizado 
la definicion, el usuario final no puede hacer una segunda definicion puesto que el 
enlazador indicaria un error. Y el creador de la clase esta forzado a crear la definicion 
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o el codigo no enlazaria en las pruebas. Esto asegura que la definicion solo sucede 
una vez y que es el creador de la clase quien la lleva a cabo. 

La expresion completa de inicializacion para un atributo estatico se realiza en el 
ambito de la clase. Por ejemplo, 

//: CIO:Statinit.cpp 

// Scope of static initializer 

#include <iostream> 

using namespace std; 

int x = 100; 

class WithStatic { 

static int x; 
static int y; 
public: 

void print() const { 

cout << "WithStatic::x = " << x << endl; 
cout << "WithStatic::y = " << y << endl; 

} 

} ; 

int WithStatic::x = 1; 
int WithStatic::y = x + 1; 

// WithStatic::x NOT ::x 

int main() { 

WithStatic ws; 
ws.print(); 

} // / : ~ 


Aqui el calificador WithStatic : : extiende el ambito de WithStatic a la defi¬ 
nicion completa. 

Inicializacion de vectores estaticos 

El capitulo 8 introdujo una variable static const que le permite definir un 
valor constante dentro del cuerpo de una clase. Tambien es posible crear arrays de 
objetos estaticos, ya sean constantes o no constantes. La sintaxis es razonablemente 
consistente: 

//: CIO:StaticArray.cpp 

// Initializing static arrays in classes 
class Values { 

// static consts are initialized in-place: 

static const int scSize = 100; 
static const long scLong = 100; 

// Automatic counting works with static arrays. 

// Arrays, Non-integral and non-const statics 
// must be initialized externally: 

static const int sclnts[]; 
static const long scLongs[]; 
static const float scTablef]; 
static const char scLetters[]; 
static int size; 














0 


0 
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static const float scFloat; 
static float table[]; 
static char letters[]; 


int Values::size = 100; 

const float Values::scFloat = 1.1; 

const int Values::sclnts[] = { 

99, 47, 33, 11, 7 

} ; 


const long Values::scLongs[] = { 
99, 47, 33, 11, 7 

} ; 


const float Values::scTable[] = { 
1.1, 2.2, 3.3, 4.4 

} ; 


const char Values::scLetters[] = { 

'a', 'b', 'c', 'd', 'e', 

'f', 'g', 'h', '£», 'j' 

} ; 


float Values::table[4] = { 
1.1, 2.2, 3.3, 4.4 

} ; 


char Values :: letters[10] = { 

'a', 'b', 'c', 'd', 'e', 

' f' , ' g' , ' h' , ' i' , ' j' 

} ; 

int main)) { Values v; } ///:- 


Usando static const de tipos enteros puede realizar las definiciones dentro 
de la clase, pero para cualquier otro tipo (incluyendo listas de enteros, incluso si es- 
tos son static const) debe realizar una unica definition externa para el atributo. 
Estas definiciones tienen enlazado interno, por lo que pueden incluirse en ficheros de 
cabecera. La sintaxis para inicializar listas estaticas es la misma que para cualquier 
agregado, incluyendo el conteo automaticoautomatic counting. 

Tambien puede crear objetos static const de tipos de clase y listas de dichos 
objetos. De todas formas, no puede inicializarlos utilizando la sintaxis tipo «inline» 
permitida para static const de tipos enteros basicos: 

//: CIO:StaticObjectArrays.cpp 
// Static arrays of class objects 

class X { 
int i; 
public: 

X (int ii) : i (ii) { } 

} ; 

class Stat { 
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// This doesn't work, although 
// you might want it to: 

//! static const X x(100); 

// Both const and non-const static class 

// objects must be initialized externally: 

static X x2; 

static X xTable2[]; 

static const X x3; 

static const X xTable3[]; 


X Stat::x2(100) ; 

X Stat::xTable2 [ ] = { 

X(1), X(2) , X(3) , X(4) 

} ; 


const X Stat::x3 (100); 

const X Stat::xTable3[] = { 

X(1), X(2) , X(3) , X(4) 

} ; 

int main() { Stat v; } ///:- 


La inicializacion de listas estaticas de objetos tanto constantes como no constan- 
tes debe realizarse de la misma manera, siguiendo la tipica sintaxis de definicion 
estatica. 


10.3.2. Clases anidadas y locales 

Puede colocar facilmente atributos estaticos en clases que estan anidadas dentro 
de otras clases. La definicion de tales miembros es intuitiva y obvia (tan solo utiliza 
otro nivel de resolucion de ambito). No obstante, no puede tener atributos estaticos 
dentro de clases locales (una clase local es una clase definida dentro de una funcion). 
Por tanto, 

//: CIO:Local.cpp 

// Static members & local classes 

#include <iostream> 

using namespace std; 

// Nested class CAN have static data members: 
class Outer { 
class Inner { 

static int i; // OK 


} ; 


int Outer::Inner::i = 47; 

// Local class cannot have static data members: 

void f() { 

class Local { 
public: 
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//! static int i; // Error 

// (How would you define i?) 
} x; 

} 


int raain() { Outer x; f(); } ///:- 


Ya puede ver el problema con atributos estaticos en clases locales: ^Como descri- 
bira el dato miembro en el ambito del fichero para poder definirlo? En la practica, el 
uso de clases locales es muy poco comun. 


10.3.3. Metodos estaticos 

Tambien puede crear metodos estaticos que, como los atributos estaticos, trabajan 
para la clase como un todo en lugar de para un objeto particular de la clase. En lugar 
de hacer una funcion global que viva en y «contamine» el espacio de nombres global 
o local, puede incluir el metodo dentro de la clase. Cuando crea un metodo estatico, 
esta expresando una asociacion con una clase particular. 

Puede llamar a un miembro estaticos de la forma habitual, con el punto o la fle- 
cha, en asociacion con un objeto. De todas formas, es mas tipico llamar a los metodos 
estaticos en si mismos, sin especificar ningun objeto, utilizando el operador de reso¬ 
lution de ambito, como en el siguiente ejemplo: 

//: CIO:SimpleStaticMemberFunction.cpp 

class X { 
public: 

static void f() {}; 

} ; 


int main () { 

X: : f <) ; 

} ///:- 


Cuando vea metodos estaticos en una clase, recuerde que el disenador pretendia 
que esa funcion estuviese conceptualmente asociada a la clase como un todo. 

Un metodo estatico no puede acceder a los atributos ordinarios, solo a los esta¬ 
ticos. Solo puede llamar a otros metodos estaticos. Normalmente, la direction del 
objeto actual (this) se pasa de forma encubierta cuando se llama a cualquier meto¬ 
do, pero un miembro static no tiene this, que es la razon por la cual no puede 
acceder a los miembros ordinarios. Por tanto, se obtiene el ligero incremento de ve- 
locidad proporcionado por una funcion global debido a que un metodo estatico no 
implica la carga extra de tener que pasar this. A1 mismo tiempo, obtiene los bene- 
ficios de tener la funcion dentro de la clase. 

Para atributos, static indica que solo existe un espacio de memoria por atributo 
para todos los objetos de la clase. Esto establece que el uso de static para definir 
objetos dentro de una funcion significa que solo se utiliza una copia de una variable 
local para todas las llamadas a esa funcion. 

Aqui aparece un ejemplo mostrando atributos y metodos estaticos utilizados con- 
juntamente: 
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//: CIO:StaticMemberFunctions.cpp 

class X { 
int i; 

static int j; 
public: 

X(int ii = 0) : i(ii) { 

// Non-static member function can access 
// static member function or data: 

j = i; 

} 

int val() const { return i; } 
static int incr() f 

//! i++; // Error: static member function 

// cannot access non-static member data 

return ++j; 

} 

static int f() { 

//! val(); // Error: static member function 
// cannot access non-static member function 
return incr(); // OK -- calls static 

} 

} ; 

int X::j = 0; 

int main ( ) { 

X x; 

X* xp = &x; 
x. f () ; 
xp—> f (); 

X::f(); // Only works with static members 

} ///:- 


Puesto que no tienen el puntero this, los metodos estaticos no pueden acceder 
a atributos no estaticos ni llamar a metodos no estaticos. 

Note el lector que en main () un miembro estatico puede seleccionarse utilizan- 
do la habitual sintaxis de punto o flecha, asociando la funcion con el objeto, pero 
tambien sin objeto (ya que un miembro estatico esta asociado con una clase, no con 
un objeto particular), utilizando el nombre de la clase y el operador de resolucion de 
ambito. 

He aqui una interesante caracteristica: Debido a la forma en la que se inicializan 
los objetos miembro estaticos, es posible poner un atributos estatico de la misma 
clase dento de dicha clase. He aqui un ejemplo que tan solo permite la existencia de 
un unico objeto de tipo Egg definiendo el constructor privado. Puede acceder a este 
objeto pero no puede crear ningun otro objeto tipo Egg: 

//: CIO:Singleton.cpp 

// Static member of same type, ensures that 
// only one object of this type exists. 

// Also referred to as the "singleton" pattern. 

#include <iostream> 

using namespace std; 

class Egg { 
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static Egg e; 
int i; 

Egg(int ii) : i(ii) {} 

Egg(const Egg& ); // Prevent copy-construction 

public: 

static Egg* instance() { return &e; } 

int val() const { return i; } 


Egg Egg::e(47); 
int main() { 

//! Egg x(l); // Error — can't create an Egg 
// You can access the single instance: 
cout << Egg::instance()->val() << endl; 

} ///:- 


La inicializacion de e ocurre una vez se completa la declaration de la clase, por 
lo que el compilador tiene toda la information que necesita para reservar espacio y 
llamar al constructor. 

Para impedir completamente la creation de cualquier otro objeto, se ha anadido 
algo mas: un segundo constructor privado llamado constructor de copin. Llegados a 
este punto del libro, usted no puede saber porque esto es necesario puesto que el 
constructor de copia no se estudiara hasta el siguiente capitulo. De todas formas, 
como un breve adelanto, si se propusiese retirar el constructor de copia definido en 
el ejemplo anterior, seria posible crear objetos Egg de la siguiente forma: 

Egg e = *Egg ::instance(); 

Egg e2( *Egg ::instance()); 

Ambos utilizan el constructor de copia, por lo que para evitar esta posibilidad, 
se declara el constructor de copia como privado (no se requiere definition porque 
nunca va a ser llamado). Buena parte del siguiente capitulo es una discusion sobre 
el constructor de copia por lo que esto quedara mas claro entonces. 


10.4. Dependencia en la inicializacion de variables 
estaticas 

Dentro de una unidad de traduction especifica, esta garantizado que el orden 
de inicializacion de los objetos estaticos sera el mismo que el de aparicion de sus 
definiciones en la unidad de traduction. 

No obstante, no hay garantias sobre el orden en que se inicializan los objetos esta¬ 
ticos entre diferentes unidades de traduction, y el lenguaje no proporciona ninguna 
forma de averiguarlo. Esto puede producir problemas significativos. Como ejemplo 
de desastre posible (que provocara el cuelgue de sistemas operativos primitivos o la 
necesidad de matar el proceso en otros mas sofisticados), si un archivo contiene: 

//: C10:Out.cpp {0} 

// First file 
#include <fstream> 

std::ofstream out("out.txt"); ///:- 















'Volumenl" — 2012/1/12 — 13:52 — page 295 — #333 


10.4. Dependencia en la inicializacion de variables estaticas 


y otro archivo utiliza el objeto out en uno de sus inicializadores 

//: CIO:Oof.cpp 
// Second file 
//{L} Out 

#include <fstream> 
extern std::ofstream out; 

class Oof { 
public: 

Oof() { out << "ouch"; } 

} oof; 

int main() {} ///:- 


el programa puede funcionar, o puede que no. Si el entorno de programacion 
construye el programa de forma que el primer archivo sea inicializado despues del 
segundo, no habra problemas. Pero si el segundo archivo se inicializa antes que el 
primero, el constructor para Oof se sustenta en la existencia de out, que todavia no 
ha sido construido, lo que causa el caos. 

Este problema solo ocurre con inicializadores de objetos estaticos que dependen 
el uno del otro. Los estaticos dentro de cada unidad de traduccion son inicializados 
antes de la primera invocacion a cualquier funcion de esa unidad, aunque puede que 
despues de main (). No puede estar seguro del orden de inicializacion de objetos 
estaticos si estan en archivos diferentes. 

Un ejemplo sutil puede encontrarse en ARM. 1 en un archivo que aparece en el 
rango global: 

extern int y; 
int x = y + 1; 


y en un segundo archivo tambien en el ambitoglobal: 

extern int x; 
int y = x + 1; 


Para todos los objetos estaticos, el mecanismo de carga-enlazado garantiza una 
inicializacion estatica a cero antes de la inicializacion dinamica especificada por el 
programador. En el ejemplo anterior, la inicializacion a cero de la zona de memoria 
ocupada por el objeto f stream out no tiene especial relevancia, por lo que real- 
mente no esta definido hasta que se llama al constructor. Pese a ello, en el caso de los 
tipos predefinidos, la inicializacion a cero si tiene importancia, y si los archivos son 
inicializados en el orden mostrado arriba, y empieza estaticamente inicializada a ce¬ 
ro, por lo que x se convierte en uno, e y es dinamicamente inicializada a dos. Pero si 
los archivos fuesen inicializados en orden opuesto, x seria estaticamente inicializada 
a cero, y dinamicamente inicializada a uno y despues, x pasaria a valer dos. 

Los programadores deben estar al tanto de esto porque puede darse el caso de 
crear un programa con dependencias de inicializacion estaticas que funcionen en una 

1 Bjarne Stroustrup and Margaret Ellis, The Annotated C++ Reference Manual, Addison-Wesley, 1990, 

pp. 20-21. 
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plataforma determinada y, de golpe y misteriosamente, compilarlo en otro entorno 
y que deje de funcionar. 


10.4.1. Que hacer 

Existen tres aproximaciones para tratar con este problema: 

1. No hacerlo. Evitar las dependencias de inicializacion estatica es la mejor solu¬ 
tion. 

2. Si debe hacerlo, coloque las definiciones de objetos estaticos criticos en un uni- 
co fichero, de forma que pueda controlar, de forma portable, su inicializacion 
colocandolos en el orden correcto. 

3. Si esta convencido que es inevitable dispersar objetos estaticos entre unida- 
des de traduction diferentes (como en el caso de una libreria, donde no puede 
controlar el programa que la usa), hay dos tecnicas de programacion para sol- 
ventar el problema. 

Tecnica uno 

El pionero de esta tecnica fue Jerry Schwarz mientras creaba la libreria iostream 
(puesto que las definiciones para cin, cout y cerr son static y residen en archi- 
vos diferentes). Realmente es inferior a la segunda tecnica pero ha pululado durante 
mucho tiempo por lo que puede encontrarse con codigo que la utilice; asi pues, es 
importante que entienda como funciona. 

Esta tecnica requiere una clase adicional en su archivo de cabecera. Esta clase es 
la responsable de la inicializacion dinamica de sus objetos estaticos de libreria. He 
aqui un ejemplo simple: 

//: CIO:Initializer.h 

// Static initialization technique 

#ifndef INITIALIZER_H 
#define INITIALIZER_H 
#include <iostream> 

extern int x; // Declarations, not definitions 

extern int y; 

class Initializer { 

static int initCount; 

public: 

Initializer() { 

std::cout << "Initializer ()" << std::endl; 

// Initialize first time only 
if(initCount++ == 0) { 

std::cout << "performing initialization" 

<< std::endl; 

x = 100; 
y = 200; 

} 

} 

-Initializer() { 

std::cout << "-Initializer()" << std::endl; 

// Clean up last time only 
if(—initCount == 0) { 
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std::cout << "performing cleanup" 
<< std::endl; 

// Any necessary cleanup here 

} 


} ; 


// The following creates one object in each 
// file where Initializer.h is included, but that 
// object is only visible within that file: 
static Initializer init; 

#endif // INITIALIZER_H ///:- 


Las declaraciones para x e y anuncian tan solo que esos objetos existen, pero 
no reservan espacio para los objetos. No obstante, la definicion para el Initial¬ 
izer init reserva espacio para ese objeto en cada archivo en que se incluya el 
archivo de cabecera. Pero como el nombre es static (en esta ocasion controlando 
la visibilidad, no la forma en la que se almacena; el almacenamiento se produce a 
nivel de archivo por defecto), solo es visible en esa unidad de traduccion, por lo que 
el enlazador no se quejara por multiples errores de definicion. 

He aqui el archivo con las definiciones para x, y e initCount: 

//: CIO:InitializerDefs.cpp {0} 

// Definitions for Initializer.h 
#include "Initializer.h" 

// Static initialization will force 
// all these values to zero: 
int x; 
int y; 

int Initializer::initCount; 

///:~ 


(Por supuesto, una instancia estdtica defichero de init tambien se incluye en este 
archivo cuando se incluye el archivo de cabecera. Suponga que otros dos archivos se 
crean por la libreria del usuario: 

//: CIO:Initializer.cpp {0} 

// Static initialization 
#include "Initializer.h" 

III:- 


y 


//: CIO:Initializers.cpp 
//{L} InitializerDefs Initializer 
// Static initialization 

#include "Initializer.h" 

using namespace std; 

int main() { 

cout << "inside main()" << endl; 
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cout << "leaving main()" << endl; 

} /// : ~ 


Ahora no importa en que unidad de traduccion se inicializa primero. La primera 
vez que una unidad de traduccion que contenga Initializer, hse inicialice, in- 
itCount sera cero por lo que la inicializacion sera llevada a cabo. (Esto depende en 
gran medida en el hecho que la zona de almacenamiento estatico esta a cero antes de 
que cualquier inicializacion dinamica se lleve a cabo). Para el resto de unidades de 
traduccion, initCount no sera cero y se eludira la inicializacion. La limpieza ocurre 
en el orden inverso, y- Initializer () asegura que solo ocurrira una vez. 

Este ejemplo utiliza tipos del lenguaje como objetos estaticos globales. Esta tec- 
nica tambien funciona con clases, pero esos objetos deben ser inicializados dinami- 
camente por la clase Initializer. Una forma de hacer esto es creando clases sin 
constructores ni destructores, pero si con metodos de inicializacion y limpieza con 
nombres diferentes. Una aproximacion mas comun, de todas formas, es tener punte- 
ros a objetos y crearlos utilizando new dentro de Initializer (). 

Tecnica dos 

Bastante despues de la aparicion de la tecnica uno, alguien (no se quien) llego 
con la tecnica explicada en esta seccion, que es mucho mas simple y limpia que la 
anterior. El hecho de que tardase tanto en descubrirse es un tributo a la complejidad 
de C++. 

Esta tecnica se sustenta en el hecho de que los objetos estaticos dentro de fun- 
ciones (solo) se inicializan la primera vez que se llama a la funcion. Tenga presente 
que el problema que estamos intentando resolver aqui no es cuando se inicializan los 
objetos estaticos (que se puede controlar separadamente) sino mas bien asegurarnos 
de que la inicializacion ocurre en el orden adecuado. 

Esta tecnica es muy limpia y astuta. Para cualquier dependencia de inicializacion, 
se coloca un objeto estatico dentro de una funcion que devuelve una referencia a ese 
objeto. De esta forma, la unica manera de acceder al objeto estatico es llamando a la 
funcion, y si ese objeto necesita acceder a otros objetos estaticos de los que depende, 
debe llamar a sus funciones. Y la primera vez que se llama a una funcion, se fuerza 
a llevar a cabo la inicializacion. Esta garantizado que el orden de la inicializacion 
sera correcto debido al diseno del codigo, no al orden que arbitrariamente decide el 
enlazador. 

Para mostrar un ejemplo, aqui tenemos dos clases que dependen la una de la 
otra. La primera contiene un bool que solo se inicializa por el constructor, por lo que 
se puede decir si se ha llamado el constructor por una instancia estatica de la clase 
(el area de almacenamiento estatico se inicializa a cero al inicio del programa, lo que 
produce un valor false para el bool si el constructor no ha sido llamado). 

//: CIO:Dependencyl.h 

#ifndef DEPENDENCY1_H 
#define DEPENDENCY1_H 
#include <iostream> 

class Dependencyl { 
bool init; 
public: 

Dependencyl() : init (true) { 

std::cout << "Dependencyl construction" 
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<< std::endl; 

} 

void print() const { 

std::cout << "Dependencyl init: " 
<< init << std::endl; 


#endif // DEPENDENCY1_H ///:- 


El constructor tambien indica cuando ha sido llamado, y es posible el estado del 
objeto para averiguar si ha sido inicializado. 

La segunda clase es inicializada por un objeto de la primera clase, que es lo que 
causa la dependencia: 

//: CIO:Dependency2.h 

#ifndef DEPENDENCY2_H 
#define DEPENDENCY2_H 
#include "Dependencyl.h" 

class Dependency2 { 

Dependencyl dl; 

public: 

Dependency2 (const DependencylS depl): dl(depl){ 
std::cout << "Dependency2 construction 
print(); 

} 

void print () const { dl.printO; } 

1 ; 

#endif // DEPENDENCY2_H ///:- 


El constructor se anuncia a si mismo y imprime el estado del objeto dl por lo que 
puede ver si este se ha inicializado cuando se llama al constructor. 

Para demostrar lo que puede ir mal, el siguiente archivo primero pone las de- 
finiciones de los objetos estaticos en el orden incorrecto, tal y como sucederia si el 
enlazador inicializase el objeto Dependency2 antes del Dependencyl. Despues se 
invierte el orden para mostrar que funciona correctamente si el orden resulta ser el 
correcto. Finalmente, se muestra la tecnica dos. 

Para proporcionar una salida mas legible, se ha creado la funcion separator (). 
El truco esta en que usted no puede llamar a la funcion globalmente a menos que 
la funcion sea utilizada para llevar a cabo la inicializacion de la variable, por lo que 
separator () devuelve un valor absurdo que es utilizado para inicializar un par 
de variables globales. 

//; CIO:Technique2.cpp 

#include "Dependency2.h" 

using namespace std; 

// Returns a value so it can be called as 
//a global initializer: 
int separator() { 

cout << " 

return 1; 


<< endl; 
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} 

// Simulate the dependency problem: 

extern Dependencyl depl; 

Dependency2 dep2(depl); 

Dependencyl depl; 
int xl = separator(); 

// But if it happens in this order it works OK: 
Dependencyl deplb; 

Dependency2 dep2b(deplb); 
int x2 = separator(); 

// Wrapping static objects in functions succeeds 

DependencylS dl() { 

static Dependencyl depl; 
return depl; 

} 

Dependency2& d2() { 

static Dependency2 dep2(dl()); 
return dep2; 

} 

int main() { 

Dependency2& dep2 = d2 () ; 

} ///:~ 


Las funciones dl () y d2 () contienen instancias estaticas de los objetos Depen¬ 
dencyl y Dependency2. Ahora, la unica forma de acceder a los objetos estaticos es 
llamando a las funciones y eso fuerza la inicializacion estatica en la primera llamada 
a la funcion. Esto significa que se garantiza la inicializacion correcta, cosa que vera 
cuando lance el programa y observe la salida. 

He aqui como debe organizar el codigo para usar esta tecnica. Ordinariamente, 
los objetos estaticos deben ser definidos en archivos diferentes (puesto que se ha vis- 
to forzado a ello por alguna razon; recuerde que definir objetos estaticos en archivos 
diferentes es lo que causa el problema), por lo que definira las funciones envoltorio 
wrapping functions) en archivos diferentes. Pero estas necesitan estar declara- 
das en los archivos de cabecera: 

//: CIO:DependencylStatFun.h 

#ifndef DEPENDENCY1STATFUN_H 
#define DEPENDENCY1STATFUN_H 
#include "Dependencyl.h" 
extern DependencylS dl(); 

#endif // DEPENDENCY!STATFUN_H ///:- 


En realidad, el «extern» es redundante para la declaration de la funcion. Este es 
el segundo archivo de cabecera: 

//: CIO:Dependency2StatFun.h 

#ifndef DEPENDENCY2STATFUN_H 
#define DEPENDENCY2STATFUN_H 
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#include "Dependency2.h" 
extern Dependency2& d2(); 

#endif // DEPENDENCY2STATFUN_H ///:- 


Ahora, en los archivos de implementation donde previamente habria situado las 
definiciones de los objetos estaticos, situara las definiciones de las funciones envol- 
torio: 

//; CIO:DependencylStatFun.cpp {0} 

#include "DependencylStatFun.h" 

DependencylS dl() { 

static Dependency1 depl; 
return depl; 

1 ///:~ 


Presumiblemente, otro codigo puede tambien componer esos archivos. He aqui 
otro archivo: 

//: CIO:Dependency2StatFun.cpp {0} 

#include "DependencylStatFun.h" 

#include "Dependency2StatFun.h" 

Dependency2& d2() { 

static Dependency2 dep2(dl()); 
return dep2; 

} ///:~ 


Ahora hay dos archivos que pueden ser enlazados en cualquier orden y si contu- 
viesen objetos estaticos ordinarios podria producirse cualquier orden de inicializa¬ 
cion. Pero como contienen funciones envoltorio, no hay posibilidad de inicializacion 
incorrecta: 

//: CIO:Technique2b.cpp 

//{L} DependencylStatFun Dependency2StatFun 
#include "Dependency2StatFun.h" 
int raain() { d2(); } ///:- 


Cuando ejecute este programa vera que la inicializacion del objeto estatico D- 
ependencyl siempre se lleva a cabo antes de la inicializacion del objeto estatico 
Dependency2. Tambien puede ver que esta es una solution bastante mas simple 
que la de la uno. 

Puede verse tentado a escribir dl () y d2 () como funciones inline dentro de 
sus respectivos archivos de cabecera, pero eso es algo que, definitivamente, no debe 
hacer. Una funcion inline puede ser duplicada en cada archivo en el que aparezca 
y esa duplication incluye la definition de los objetos estaticos. Puesto que las funcio¬ 
nes inline llevan asociado por defecto enlazado inferno, esto provocara la apari- 
cion de multiples objetos estaticos entre las diversas unidades de traduction, lo que 
ciertamente causara problemas. Es por eso que debe asegurarse que solo existe una 
unica definition para cada funcion contenedora, y eso significa no hacerlas inline. 
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10.5. Especificaciones de enlazado alternativo 

^Que pasa si esta escribiendo un programa en C++ y quiere usar una libreria de 
C? Si hace uso de la declaracion de funciones de C, 

I float f (int a, char b); 


el compilador de C++ adornara el nombre como algo tipo _f_int_char para 
permitir la sobrecarga de la funcion (y el enlazado con verificacion de tipos). De to- 
das formas, el compilador de C que compilo su libreria C definitivamente no decoro 
ese nombre, por lo que su nombre inferno sera _f. Asi pues, el enlazador no sera 
capaz de resolver sus llamadas tipo C++ a f (). 

La forma de resolver esto que se propone en C++ es la especificacion de enlazado 
alternativo, que se produjo en el lenguaje sobrecargando la palabra clave extern. A 
la palabra clave extern le sigue una cadena que especifica el enlazado deseado para 
la declaracion, seguido por la declaracion: 

extern "C" float f(int a, char b); 

Esto le dice al compilador que f () tiene enlazado tipo C, de forma que el compi¬ 
lador no decora el nombre. Las dos unicas especificaciones de enlazado soportadas 
por el estandar son «C» y «C++», pero algunos vendedores ofrecen compiladores 
que tambien soportan otros lenguajes. 

Si tiene un grupo de declaraciones con enlazado alternativo, pongalas entre Ha¬ 
ves, como a continuacion: 

extern "C" { 

float f(int a, char b); 
double d(int a, char b); 

} 


O, para archivos de cabecera, 

extern "C" { 

#include "Myheader.h" 

} 


La mayoria de compiladores disponibles de C++ manejan las especificaciones de 
enlazado alternativo dentro de sus propios archivos de cabecera que trabajan tanto 
con C como con C++, por lo que no tiene que preocuparse de eso. 


10.6. Resumen 

La palabra clave static puede llevar a confusion porque en algunas situacio- 
nes controla la reserva de espacio en memoria, y en otras controla la visibilidad y 
enlazado del nombre. 

Con la introduccion de los espacios de nombres de C++, dispone de una alterna- 
tiva mejorada y mas flexible para controlar la proliferation de nombres en proyectos 
grandes. 
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El uso de static dentro de clases es un metodo mas para controlar los nombres 
de un programa. Los nombres no colisionan con nombres globales, y la visibilidad y 
acceso se mantiene dentro del programa, dandole un mayor control para el mante- 
nimiento de su codigo. 


10.7. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Cree una funcion con una variable estatica que sea un puntero (con un argu- 
mento por defecto igual cero). Cuando la funcion que realice la llamada pro- 
porcione un valor para ese argumento se usara para apuntar al principio de un 
array de int. Si se llama a la funcion con el argumento cero (utilizando el argu¬ 
mento por defecto), la funcion devuelve el siguiente valor del array, hasta que 
llegue a un valor -1 en el array (que actuara como serial de final). Experimente 
con esta funcion en main (). 

2. Cree una funcion que devuelva el siguiente valor de una serie de Fibonacci 
cada vez que sea llamada. Anada un argumento que de tipo bool con valor por 
defecto false tal que cuando el argumento valga true «reinicie» la funcion 
al principio de la serie de Fibonacci. Experimente con esta funcion en main (). 

3. Cree una clase que contenga un array de int. Especifique la dimension del array 
utilizando static const int dentro de la clase. Anada una variable const 
int e inicialicela en la lista de inicializacion del constructor. Haga al construc¬ 
tor inline. Anada un atributo static int e inicialicelo a un valor especifico. 
Anada un metodo estatico que imprima el atributo estatico. Anada un miem- 
bro inline llamado print () que imprima todos los valores del array y que 
llame al metodo estatico. Experimente con esta clase en main (). 

4. Cree una clase llamada Monitor que mantenga el registro del mimero de veces 
que ha sido llamado su metodo incident (). Anada un metodo print () que 
muestre por pantalla el mimero de incidentes. Ahora cree una funcion global 
(no un metodo) que contenga un objeto estatico Monitor. Cada vez que llame 
a la funcion debe llamar a incident (), despues al metodo print () para 
sacar por pantalla el contador de incidentes. Experimente con la funcion en 
main (). 

5. Modifique la clase Monitor del Ejercicio 4 de forma que pueda decrementar 
(decrement ()) el contador de incidentes. Cree una clase llamada Monitor2 
que tome como argumento del constructor un puntero aMonitorl, y que al- 
macene ese puntero y llame a incident () y print (). En el destructor para 
Monitor2, llame a decrement () y print (). Cree ahora un objeto estatico 
de Monitor2 dentro de una funcion. Dentro de main (), experimente llaman- 
do y no llamando a la funcion para ver que pasa con el destructor de Monit- 
or2. 

6. Cree un objeto global de clase Monitor2 y vea que sucede. 

7. Cree una clase con un destructor que imprima un mensaje y despues llame a 
exit (). Cree un objeto global de esa clase y vea que pasa. 
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8. En StaticDestructors . cpp, experimente con el orden de llamada de los 
constructores y destructores llamando a f () y g () dentro de main () en dife- 
rentes ordenes. ^Su compilador inicializa los objetos de la forma correcta? 

9. En StaticDestructors . cpp, pruebe el manejo de errores por defecto de 
su implementation convirtiendo la definicion original de out dentro de una 
declaration extern, y poniendo la definicion real despues de la definicion 
de a (donde el constructor de Ob j manda information a out). Asegurese que 
no hay ningun otro programa importante funcionando en su maquina cuando 
ejecute el codigo o que su maquina maneje las faltas robustamente. 

10. Pruebe que las variables estaticas de fichero en los archivos de cabecera no 
chocan entre si cuando son incluidas en mas de un archivo cpp. 

11. Cree una unica clase que contenga un int, un constructor que inicialice el int 
con su argumento, un metodo que cambie el valor del int con su argumento y 
una funcion print ( ) que muestre por pantalla el int. Coloque su clase en un 
archivo de cabecera e incluya dicho archivo en dos archivos cpp. En uno de 
ellos cree una instancia de la clase y en la otra declare ese identificador como 
extern y pruebe dentro de main (). Recuerde, debe enlazar los dos archivos 
objeto o de lo contrario el enlazador no encontrara el objeto. 

12. Cree la instancia del objeto del Ejercicio 11 como static y verifique que, de- 
bido a eso, el enlazador es incapaz de encontrarla. 

13. Declare una funcion en un archivo de cabecera. Defina la funcion en un archivo 
cpp y llamela desde main () en un segundo archivo cpp. Compile y verifique 
que funciona. Ahora cambie la definicion de la funcion de forma que sea sta¬ 
tic y verifique que el enlazador no puede encontrarla. 

14. Modifique Volatile . cpp del Capitulo 8 para hacer que comm: : isr ( ) fun- 
cione realmente como una rutina de servicio de interrupcion. Pista: una rutina 
de servicio de interrupcion no toma ningun argumento. 

15. Escriba y compile un unico programa que utilice las palabras clave auto y 
register. 

16. Cree un archivo de cabecera que contenga un espacio de nombres. Dentro del 
espacio de nombres cree varias declaraciones de funciones. Cree ahora un se¬ 
gundo archivo de cabecera que incluya el primero y continue el espacio de 
nombres, ahadiendo varias declaraciones de funciones mas. Cree ahora un ar¬ 
chivo cpp que incluya el segundo archivo de cabecera. Cambie su espacio de 
nombres a otro nombre (mas corto). Dentro de una definicion de funcion, 11a- 
me a una de sus funciones utilizando la resolucion de ambito. Dentro de una 
definicion de funcion separada, escriba una directiva using para introducir su 
espacio de nombres en el ambito de esa funcion, y demuestre que no necesita 
utilizar la resolucion de ambito para llamar a las funciones desde su espacio de 
nombres. 

17. Cree un archivo de cabecera con un espacio de nombres sin nombre. Incluya 
la cabecera en dos archivos cpp diferentes y demuestre que un espacio sin 
nombre es unico para cada :unidad de traduccion. 

18. Utilizando el archivo de cabecera del Ejercicio 17, demuestre que los nombres 
de un espacio de nombres sin nombre estan disponibles automaticamente en 
una :unidad de traduccion sin calificacion. 
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19. Modifique Friendln jection . cpp para anadir una definicion para la fun- 
cion amiga y para llamar a la funcion desde main ( ). 

20. En Arithmetic . cpp, demuestre que la directiva using no se extiende fuera 
de la funcion en la que fue creada. 

21. Repare el problema de OverridingAmbiguity. cpp, primero con resolucion 
de ambito y luego, con una declaracion using que fuerce al compilador a es- 
cojer uno de los nombres de funcion identicos. 

22. En dos archivos de cabecera, cree dos espacios de nombres, cada uno conte- 
niendo una clase (con todas las definiciones inline) con identico nombre que 
el del otro espacio de nombres. Cree un archivo cpp que incluya ambos archi¬ 
vos. Cree una funcion y, dentro de la funcion, utilice la directiva using para 
introducir ambos espacios de nombres. Pruebe a crear un objeto de la clase y 
vea que sucede. Haga las directivas using globales (fuera de la funcion) pa¬ 
ra ver si existe alguna diferencia. Repare el problema usando la resolucion de 
ambito, y cree objetos de ambas clases. 

23. Repare el problema del Ejercicio 22 con una declaracion using que fuerce al 
compilador a escojer uno de los nombres de clase identicos. 

24. Extraiga las declaraciones de espacios de nombres de Bobs SuperDuperLibrary . 
cpp y UnnamedNamespaces . cpp y pongalos en archivos separados, dando 

un nombre al espacio de nombres sin nombre en el proceso. En un tercer archi¬ 
vo de cabecera, cree un nuevo espacio de nombres que combine los elementos 
de los otros dos espacios de nombres con declaraciones using. En main (), 
introduzca su nuevo espacio de nombres con una directiva using y acceda a 
todos los elementos de su espacio de nombres. 

25. Cree un archivo de cabecera que incluya <string> y <iostream> pero que 
no use ninguna directiva using ni ninguna declaracion using. Anada guar- 
das de inclusion como ha visto en los archivos de cabecera del libro. Cree una 
clase con todas las funciones inline que muestre por pantalla el string. Cree 
un archivo cpp y ejercite su clase en main () . 

26. Cree una clase que contenga un static double y long. Escriba un metodo estatico 
que imprima los valores. 

27. Cree una clase que contenga un int, un constructor que inicialice el int con 
su argumento, y una funcion print () que muestre por pantalla el int. Cree 
ahora una segunda clase que contenga un objeto estatico de la primera. Anada 
un metodo estatico que llame a la funcion print () del objeto estatico. Ejercitu 
su clase en main (). 

28. Cree una clase que contenga un array estatico de int constante y otro no cons- 
tante. Escriba metodos estaticos que impriman los arrays. Experimente con su 
clase en main (). 

29. Cree una clase que contenga un string, con un constructor que inicialice el 
string a partir de su argumento, y una funcion print () que imprima el string. 
Cree otra clase que contenga un array estatico, tanto constante como no cons¬ 
tante, de objetos de la primera clase, y metodos estaticos para imprimir dichos 
arrays. Experimente con la segunda clase en main () . 

30. Cree una st ruct que contenga un int y un constructor por defecto que iniciali¬ 
ce el int a cero. Haga ese struct local a una funcion. Dentro de dicha funcion, 
cree un array de objetos de su struct y demuestre que cada int del array ha 
sido inicializado a cero automaticamente. 
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31. Cree una clase que represente una conexion a impresora, y que solo le permita 
tener una impresora. 

32. En un archivo de cabecera, cree una clase Mirror que contiene dos atributos: 
un puntero a un objeto Mirror y un bool. Dele dos constructores: el cons¬ 
tructor por defecto inicializa el bool a true y el puntero a Mirror a cero. El 
segundo constructor toma como argumento un puntero a un objeto Mirror, 
que asigna al puntero interno del objeto; pone el bool a false. Anada un me- 
todo test () : si el puntero del objeto es distinto de cero, devuelve el valor de 
test () llamado a traves del puntero. Si el puntero es cero, devuelve el bool. 
Cree ahora cinco archivos cpp, cada uno incluyendo la cabecera Mirror. El 
primer archivo cpp define un objeto Mirror global utilizando el constructor 
por defecto. El segundo archivo declara el objeto del primer archivo como e- 
xtern, y define un objeto Mirror global utilizando el segundo constructor, 
con un puntero al primer objeto. Siga haciendo lo mismo hasta que llegue al 
ultimo archivo, que tambien contendra una definition de objeto global. En este 
archivo, main ( ) debe llamar a la funcion test () e informar del resultado. Si 
el resultado es t rue, encuentre la forma de cambiar el orden de enlazado de 
su enlazador y cambielo hasta que el resultado sea false. 

33. Repare el problema del Ejercicio 32 utilizando la tecnica uno mostrada en este 
libro. 

34. Repare el problema del Ejercicio 32 utilizando la tecnica dos mostrada en este 
libro. 

35. Sin incluir ningun archivo de cabecera, declare la funcion puts () de la Libre- 
ria Estandar de C. Llame a esa funcion desde main (). 
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11: Las referencias y el constructor 
de copia 

Las referencias son como punteros constantes que el compilador 
de-referencia automaticamente. 

Aunque las referencias tambien existen en Pascal, la version de C++ se tomo del 
lenguaje Algol. Las referencias son esenciales en C++ para ayudar en la sintaxis de 
los operadores sobrecargados (vea el capltulo 12) y, ademas, son una buena forma 
para controlar la manera en que los argumentos se pasan a las funciones tanto hacia 
dentro como hacia fuera. 

En este capltulo primero vera la diferencia entre los punteros en C y en C++, y 
luego se presentaran las referencias. Pero la mayor parte del capltulo ahondara en el 
asunto un tanto confuso para los programadores de C++ novatos: el constructor de 
copia, un constructor especial (que usa referencias) y construye un nuevo objeto de 
otro ya existente del mismo tipo. El compilador utiliza el constructor de copia para 
pasar y retornar objetos por valor a las funciones. 

Finalmente, se hablara sobre la caracterlstica (un tanto oscura) de los punteros-a- 
miembro de C++. 


11.1. Punteros en C++ 

La diferencia mas importante entre los punteros en C y en C++ es que los de 
C++ estan fuertemente tipados. Sobre todo en lo que al tipo void * se refiere. C no 
permite asignar un puntero de un tipo a otro de forma casual, pero si permite hacerlo 
mediante un void *. Por ejemplo. 

Bird* b; 

Rock* r; 
void* v; 
v = r; 
b = v; 


A causa de esta «caracterlstica» de C, puede utilizar cualquier tipo como si de 
otro se tratara sin ningun aviso por parte del compilador. C++ no permite hacer esto; 
el compilador da un mensaje de error, y si realmente quiere utilizar un tipo como otro 
diferente, debe hacerlo expllcitamente, tanto para el compilador como para el lector, 
usando molde (cast en ingles). (En el capltulo 3 se hablo sobre la sintaxis mejorada 
del molde «explicito»). 
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11.2. Referencias en C++ 

Una referenda (&) es como un puntero constante que se de-referencia automatica- 
mente. Normalmente se utiliza en la lista de argumentos y en el valor de retorno de 
de las funciones. Pero tambien se puede hacer una referenda que apunte a algo que 
no ha sido asignado. Por ejemplo: 

//: Cll:FreeStandingReferences.cpp 

#include <iostream> 

using namespace std; 

// Ordinary free-standing reference: 

int y; 
int& r = y; 

// When a reference is created, it must 
//be initialized to a live object. 

// However, you can also say: 
const int& q = 12; // (1) 

// References are tied to someone else's storage: 


int x = 0; 


// (2) 


int& a = x 

r 

// (3) 


int main() 

{ 



cout << 

”x = 

" « x << ", 

a = " << a << endl; 

a++; 




cout << 

”x = 

" « X « ", 

a = " << a << endl; 

} ///:- 





En la linea (1) el compilador asigna la cantidad necesaria de memoria, la inicializa 
con el valor 12, y liga la referenda a esa porcion de memoria. Lo importante es que 
una referenda debe estar ligada a la memoria de alguien. Cuando se accede a una 
referencia, se esta accediendo a esa memoria. Asi pues, si escribe las lineas (2) y (3) 
incrementara x cuando se incremente a, tal como se muestra en el main (). Lo mas 
facil es pensar que una referencia es como un puntero de lujo. La ventaja de este 
«puntero» es que nunca hay que preguntarse si ha sido inicializado (el compilador 
lo impone) o si hay que destruirlo (el compilador lo hace). 

Hay que seguir unas determinadas reglas cuando se utilizan referencias: 

1. La referencia de ser inicializada cuando se crea. (Los punteros pueden iniciali- 
zarse en cualquier momento). 

2. Una vez que se inicializa una referencia, ligandola a un objeto, no se puede 
ligar a otro objeto. (Los punteros pueden apuntar a otro objeto en cualquier 
momento). 

3. No se pueden tener referencias con valor nulo. Siempre ha de suponer que una 
referencia esta conectada a una trozo de memoria ya asignada. 


11.2.1. Referencias en las funciones 

El lugar mas comun en el que vera referencias es en los argumentos y valor de re¬ 
torno de las funciones. Cuando se utiliza una referencia como un argumento de una 
funcion, cualquier cambio realizado en la referencia dentro de la funcion se realizara 
realmente sobre el argumento fuera de la funcion. Por supuesto que podria hacer lo 
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mismo pasando un puntero como argumento, pero una referenda es sintacticamente 
mas clara. (Si lo desea, puede pensar que una referencia es, nada mas y nada menos, 
mas conveniente sintacticamente). 

Si una funcion retorna una referencia, ha de tener el mismo cuidado que si la 
funcion retornara un puntero. La referencia que se devuelva debe estar ligada a algo 
que no sea liberado cuando la funcion retorne. Si no, la referencia se referira a un 
trozo de memoria sobre el que ya no tiene control. 

He aqui un ejemplo: 

//: Cll:Reference.cpp 
// Simple C++ references 

int* f (int* x) { 

(*x)++; 

return x; // Safe, x is outside this scope 

} 


int& g(int& x) { 

x++; // Same effect as in f() 
return x; // Safe, outside this scope 

} 


int& h () { 

int q; 

//! return q; // Error 

static int x; 

return x; // Safe, x lives outside this scope 

} 


int main() { 

int a = 0; 

f(&a); // Ugly (but explicit) 
g(a); // Clean (but hidden) 

} ///:- 


La llamada a f () no tiene la ventaja ni la claridad que la utilizacion de referen¬ 
cias, pero esta claro que se esta pasando una direccion mediante un puntero. En la 
llamada a g (), tambien se pasa una direccion (mediante una referencia), pero no se 
ve. 


Referencias constantes 

El argumento referencia en Reference . cpp funciona solamente en caso de que 
el argumento no sea un objeto constante. Si fuera un objeto constante, la funcion g () 
no aceptaria el argumento, lo cual es positivo porque la funcion modificaria el argu¬ 
mento que esta fuera de la funcion. Si sabe que la funcion respetara las constancia un 
objeto, el hecho de que el argumento sea una referencia constante permitira que la 
funcion se pueda utilizar en cualquier situacion. Esto significa que para tipos prede- 
finidos, la funcion no modificara el argumento, y para tipos definidos por el usuario, 
la funcion llamara solamente a metodos constantes, y no modificara ningun atributo 
publico. 

La utilizacion de referencias constantes en argumentos de funciones es especial- 
mente importante porque una funcion puede recibir un objeto temporal. Este podria 
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haber sido creado como valor de retorno de otra funcion o explicitamente por el 
usuario de la funcion. Los objetos temporales son siempre constantes. Por eso, si no 
utiliza una referencia constante, el compilador se quejara. Como ejemplo muy sim¬ 
ple: 

//: Cll:ConstReferenceArguments.cpp 
// Passing references as const 

void f(int&) {} 

void g(const int&) {} 

int main () { 

//! f (1); // Error 

g (l); 

} ///:- 


La llamada f ( 1 ) provoca un error en tiempo de compilacion porque el compi¬ 
lador debe crear primero una referencia. Lo hace asignando memoria para un int, 
inicianlizandolo a uno y generando la direccion de memoria para ligarla a la re¬ 
ferencia. La memoria debe ser constante porque no tendria sentido cambiarlo: no 
puede cambiarse de nuevo. Puede hacer la misma suposicion para todos los objetos 
temporales: son inaccesibles. Es importante que el compilador le diga cuando esta 
intentando cambiar algo de este estilo porque podria perder informacion. 

Referencias a puntero 

En C, si desea modificar el contenido del puntero en si en vez de modificar a lo 
que apunta, la declaracion de la funcion serf a: 

void f (int**); 

y tendria que tomar la direccion del puntero cuando se llamara a la funcion: 

int i = 47; 
int* ip = &i; 
f(& ip); 


La sintaxis es mas clara con las referencias en C++. El argumento de la funcion 
pasa a ser de una referencia a un puntero, y asi no ha de manejar la direccion del 
puntero. 

//: Cll :ReferenceToPointer.cpp 

#include <iostream> 

using namespace std; 

void increment (int*& i) { i++; } 


int main () { 

int* i = 0; 

cout << "i = " << i << endl; 
increment(i); 
cout << "i = 

} ///:~ 


<< i << endl; 



© 


© 


© 
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A1 ejecutar este programa se observa que el puntero se incrementa en vez de 
incrementar a lo que apunta. 


11.2.2. Consejos para el paso de argumentos 

Cuando se pasa un argumento a un funcion, lo normal deberia ser pasarlo como 
una referenda constante. Aunque al principio puede parecer que solo tiene ventajas 
en terminos de eficacia (y normalmente en diseno e implementation initial no se 
tiene muy en cuenta la eficacia), ademas tiene otras: como se podra ver en el resto 
del capitulo, se requiere un constructor de copia para pasar un objeto por valor, y 
esto no siempre es posible. 

La eficacia puede mejorar substancialmente por este simple habito: pasar un ar¬ 
gumento por valor necesita una llamada a un constructor y otra a un destructor, 
pero si no se va a modificar el argumento, el hecho de pasarlo como una referenda 
constante solo necesita poner una direction en la pila. 

De hecho, practicamente la unica situation en la que no es preferible pasar la 
direction, es cuando provocara tales problemas a un objeto que pasar por valor es la 
unica alternativa segura (en vez de modificar el objeto que esta fuera del ambito de 
la funcion, algo que el que llama a la funcion normalmente no espera). Ese es el tema 
de la siguiente section. 


11.3. El constructor de copia 

Ahora que entiende lo basico de las referencias en C++, esta preparado para tratar 
uno de los conceptos mas confusos del lenguaje: el constructor de copia, a menudo 
denominado X (X& ) («X de la referenda X»). Este constructor es esencial para con- 
trolar el paso y retorno por valor de los tipos definidos por el usuario en las llamadas 
a funciones. De hecho es tan importante que el compilador crea automaticamente un 
constructor de copia en caso de que el programador no lo proporcione. 


11.3.1. Paso y retorno por valor 

Para entender la necesidad del constructor de copia, considere la forma en que 
C maneja el paso y retorno por valor de variables cuando se llama a una funcion. Si 
declara una funcion y la invoca, 

int f(int x, char c); 
int g = f (a, b) ; 

^como sabe el compilador como pasar y retornar esas variables? jSimplemente lo 
sabe! El rango de tipos con los que debe tratar es tan pequeno (char, int, float, double, 
y sus variaciones), que tal information ya esta dentro del compilador. 

Si averigua como hacer que su compilador genere codigo ensamblador y deter- 
mina que instrucciones se usan para la invocation de la funcion f (), obtendra algo 
equivalente a: 

push b 
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push a 

call f() 

add sp, 4 

mov g, register a 


Este codigo se ha simplificado para hacerlo generico; las expresiones b y a seran 
diferentes dependiendo de si las variables son globales (en cuyo caso serian _b y 
_a) o locales (el compilador las pondria en la pila). Esto tambien es cierto para g. 
La sintaxis de la llamada a f () dependeria de su guia de estilo, y register a 
dependeria de como su ensamblador llama a los registros de la CPU. A pesar de la 
simplification, la logica del codigo serf a la misma. 

Tanto en C como en C++, primero se ponen los argumentos en la pila de derecha 
a izquierda, y luego se llama a la funcion. El codigo de llamada es responsable de 
recoger los argumentos de la pila (lo cual explica la sentencia add sp, 4). Pero ten- 
ga en cuenta que cuando se pasan argumentos por valor, el compilador simplemente 
pone copias en la pila (conoce los tamanos de cada uno, por lo que los puede copiar). 

El valor de retorno de f () se coloca en un registro. Como el compilador sabe lo 
que se esta retornando, porque la informacion del tipo ya esta en el lenguaje, puede 
retornarlo colocandolo en un registro. En C, con tipos primitivos, el simple hecho de 
copiar los bits del valor es equivalente a copiar el objeto. 

Paso y retorno de objetos grandes 

Considere ahora los tipos definidos por el usuario. Si crea una clase y desea pasar 
un objeto de esa clase por valor, ^como sabe el compilador lo que tiene que hacer? 
La informacion de la clase no esta en el compilador, pues lo ha definido el usuario. 

Para investigar esto, puede empezar con una estructura simple que, claramente, 
es demasiado grande para ser devuelta a traves de los registros: 

//: Cll:PassingBigStructures.cpp 

struct Big { 
char buf[100]; 
int i; 
long d; 

} B, B2; 

Big bigfun(Big b) { 

b.i = 100; // Do something to the argument 

return b; 

} 


int main () { 

B2 = bigfun (B); 

} ///:~ 


La conversion a codigo ensamblador es un poco mas complicada porque la ma- 
yoria de los compiladores utilizan funciones «auxiliares» ( helper ) en vez de inline. En 
la funcion main (), la llamada a bigfun () empieza como debe: se coloca el conteni- 
do de B en la pila. (Aqui podria ocurrir que algunos compiladores carguen registros 
con la direction y tamano de Big y luego una funcion auxiliar se encargue de colocar 
el Big en la pila). 

En el fragmento de codigo fuente anterior, lo unico necesario antes de llamar a la 
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funcion es colocar los argumentos en la pila. Sin embargo, en el codigo ensamblador 
de PassingBigStructures . cpp se ve una accion adicional: la direccion de B2 
se coloca en la pila antes de hacer la llamada a la funcion aunque, obviamente, no 
sea un argumento. Para entender que pasa, necesita entender las restricciones del 
compilador cuando llama a una funcion. 

Marco de pila para llamadas a funcion 

Cuando el compilador genera codigo para llamar a una funcion, primero coloca 
en la pila todos los argumentos y luego hace la llamada. Dentro de la funcion se 
genera codigo para mover el puntero de pila hacia abajo, y asf proporciona memoria 
para las variables locales dentro de la funcion. («hacia abajo» es relativo, la maquina 
puede incrementar o decrementar el puntero de pila al colocar un argumento). Pero 
cuando se hace el CALL de ensamblador para llamar a la funcion, la CPU coloca 
la direccion desde la que se realiza la llamada, y en el RETURN de ensamblador se 
utiliza esa direccion para volver al punto desde donde se realizo la llamada. Esta 
direccion es sagrada, porque sin ella el programa se perderia por completo. He aqui 
es aspecto del marco de pila despues de ejecutar CALL y poner las variables locales 
de la funcion: 


Argumentos de la funcion 


Direccion de retorno 


Variables locales 


Figura 11.1: Llamada a una funcion 


El codigo generado por el resto de la funcion espera que la memoria tenga esta 
disposicion para que pueda utilizar los argumentos y las variables locales sin tocar 
la direccion de retorno. Llamese a este bloque de memoria, que es todo lo que una 
funcion necesita cuando se la llama, el marco de la funcion (function frame). 

Podria parecer razonable retornar valores mediante la utilization de la pila. El 
compilador simplemente los colocaria alii y la funcion devolveria un desplazamiento 
que indicara donde empieza el valor de retorno. 

Re-entrada 

Este problema ocurre porque las funciones en C y C++ pueden sufrir interrupcio- 
nes; esto es, los lenguajes han de ser (y de hecho son) re-entrantes. Tambien permiten 
llamadas a funciones recursivas. Esto quiere decir que en cualquier punto de exe¬ 
cution de un programa puede sufrir una interruption sin que el programa se vea 
afectado por ello. Obviamente la persona que escribe la rutina de servicio de inte- 
rrupciones (ISR) es responsable de guardar y restaurar todos los registros que se 
utilicen en la ISR. Pero si la ISR necesita utilizar la pila, ha de hacerlo con seguridad. 
(Piense que una ISR es como una funcion normal sin argumentos y con valor de re¬ 
torno void que guarda y restaura el estado de la CPU. La ejecucion de una ISR suele 
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producirse por un evento hardware, y no con una invocation dentro del programa 
de forma explicita). 

Ahora imagine que pasaria si una funcion normal intentara retornar valores me- 
diante la pila. No puede tocar la pila por encima del la direccion de retorno, as! que 
la funcion tendria que colocar los valores de retorno debajo de la direccion de re¬ 
torno. Pero cuando se ejecuta el RETURN, el puntero de pila deberia estar apuntando 
a la direccion de retorno (o justo debajo, depende de la maquina), as! que la funcion 
debe subir el puntero de la pila, desechando todas las variables locales. Si intenta re¬ 
tornar valores usando la pila por debajo de la direccion de retorno, en ese momento 
es vulnerable a una interrupcion. La ISR escribiria encima de los valores de retorno 
para colocar su direccion de retorno y sus variables locales. 

Para resolver este problema, el que llama a la funcion podria hacerse responsable 
de asignar la memoria extra en la pila para los valores de retorno antes de llamar a 
la funcion. Sin embargo, C no se diseno de esta manera y C++ ha de ser compatible. 
Como vera pronto, el compilador de C++ utiliza un esquema mas eficaz. 

Otra idea seria retornar el valor utilizando un area de datos global, pero tampoco 
funcionaria. La re-entrada significa que cualquier funcion puede ser una rutina de 
interrupcion para otra funcion, incluida la funcion que se estd ejecutando. Por lo tanto, si 
coloca un valor de retorno en un area global, podria retornar a la misma funcion, lo 
cual sobreescribiria el valor de retorno. La misma logica se aplica a la recursividad. 

Los registros son el unico lugar seguro para devolver valores, asi que se vuelve al 
problema de que hacer cuando los registros no son lo suficientemente grandes para 
contener el valor de retorno. La respuesta es colocar la direccion de la ubicacion del 
valor de retorno en la pila como uno de los argumentos de la funcion, y dejar que la 
funcion copie la information que se devuelve directamente en esa ubicacion. Esto no 
solo soluciona todo los problemas, si no que ademas es mas eficaz. Esta es la razon 
por la que el compilador coloca la direccion de B2 antes de llamar abigfunenla 
funcion main () de PassingBigStructures . cpp. Si viera el codigo ensamblador 
de bigfun () observaria que la funcion espera este argumento escondido y lo copia 
al destino dentro de la funcion. 

Copia bit a bit vs. inicializacion 

Hasta aqui, todo bien. Tenemos un procedimiento para pasar y retornar estruc- 
turas simples grandes. Pero note que lo unico que tiene es una manera de copiar bits 
de un lugar a otro, lo que ciertamente funciona bien para la forma (muy primitiva) 
en que C trata las variables. Sin embargo, en C++ los objetos pueden ser mucho mas 
avanzados que un punado de bits, pues tienen significado y, por lo tanto, puede que 
no responda bien al ser copiado. 

Considere un ejemplo simple: una clase que conoce cuantos objetos de un tipo 
existen en cualquier momento. En el Capitulo 10 se vio la manera de hacerlo inclu- 
yendo un atributo estatico (static): 

//: Cll:HowMany.cpp 

// A class that counts its objects 

#include <fstream> 

#include <string> 

using namespace std; 

ofstream out("HowMany.out"); 

class HowMany { 

static int objectCount; 
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public: 

HowMany() { objectCount++; } 

static void print (const strings msg = "") { 

if (msg.size() != 0) out << msg << 

out << "objectCount = " 

<< objectCount << endl; 

} 

-HowMany() { 

objectCount—; 
print("-HowMany()") ; 


} ; 


int HowMany::objectCount = 0; 

// Pass and return BY VALUE: 

HowMany f(HowMany x) { 

x.print("x argument inside f()"); 

return x; 


int main () { 

HowMany h; 

HowMany::print("after construction of h"); 
HowMany h2 = f(h) ; 

HowMany::print("after call to f()"); 

} ///:- 


La clase HowMany contiene un entero estatico llamado objectCount y un meto- 
do estatico llamado print () para representar el valor de objectCount, junto con 
argumento de mensaje opcional. El constructor incrementa objectCount cada vez 
que se crea un objeto, y el destructor lo disminuye. 

Sin embargo la salida no es la que cabria esperar: 


after construction of h: objectCount = 1 
x argument inside f(): objectCount = 1 
~HowMany(): objectCount = 0 
after call to f(): objectCount = 0 
~HowMany(): objectCount = -1 
~HowMany(): objectCount = -2 


Despues de crear h, el contador es uno, lo cual esta bien. Pero despues de la 
llamada a f () se esperaria que el contador estuviera a dos, porque h2 esta ahora 
tambien dentro de ambito. Sin embargo, el contador es cero, lo cual indica que algo 
ha ido muy mal. Esto se confirma por el hecho de que los dos destructores, llamados 
al final de main (), hacen que el contador pase a ser negativo, algo que no deberia 
ocurrir nunca. 

Mire lo que ocurre dentro de f () despues de que el argumento se pase por valor. 
Esto quiere decir que el objeto original h existe fuera del ambito de la funcion y, por 
otro lado, hay un objeto de mas dentro del ambito de la funcion, que es copia del ob¬ 
jeto que se paso por valor. El argumento que se paso utiliza el primitivo concepto de 
copia bit a bit de C, pero la clase C++ HowMany necesita inicializarse correctamen- 
te para mantener su integridad. Por lo tanto, se demuestra que la copia bit a bit no 
logra el efecto deseado. 

Cuando el objeto local sale de ambito al acabar la funcion f (), se llama a su 
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destructor, lo cual decrementa objectCount, y por lo tanto el ob jectCount se 
pone a cero. La creacion de h2 se realiza tambien mediante la copia bit a bit, asi que 
tampoco se llama al constructor, y cuando h y h2 salen de ambito, sus destructores 
causan el valor negativo en objectCount. 


11.3.2. Construccion por copia 

El problema se produce debido a que el compilador hace una suposicion sobre 
como crear un nuevo objeto a partir de de otro existente. Cuando se pasa un objeto por 
valor, se crea un nuevo objeto, que estara dentro del ambito de la funcion, a partir 
del objeto original existente fuera del ambito de la funcion. Esto tambien se puede 
aplicar a menudo cuando una funcion retorna un objeto. En la expresion 

HowMany h2 = f (h); 


h2, un objeto que no estaba creado anteriormente, se crea a partir del valor que 
retorna f (); por tanto tambien se crea un nuevo objeto a partir de otro existente. 

El compilador supone que la creacion ha de hacerse con una copia bit a bit, lo 
que en muchos casos funciona bien, pero en HowMany no funciona porque la inicia- 
lizacion va mas alia de una simple copia. Otro ejemplo muy comun ocurre cuando 
la clase contiene punteros pues, ^a que deben apuntar? ^deberia copiar solo los pun- 
teros o deberia asignar memoria nueva y que apuntaran a ella? 

Afortunadamente, puede intervenir en este proceso e impedir que el compilador 
haga una copia bit a bit. Se soluciona definiendo su propia funcion cuando el com¬ 
pilador necesite crear un nuevo objeto a partir de otro. Logicamente, esta creando 
un nuevo objeto, por lo que esta funcion es un constructor, y el unico argumento del 
constructor tiene que ver con el objeto del que se pretende partir para crear el nue¬ 
vo. Pero no puede pasar ese objeto por valor al constructor porque esta intentando 
definir la funcion que maneja el paso por valor, y, por otro lado, sintacticamente no 
tiene sentido pasar un puntero porque, despues de todo, esta creando un objeto a 
partir de de otro. Aqui es cuando las referencias vienen al rescate, y puede utilizar la 
referenda del objeto origen. Esta funcion se llama constructor de copia, que tambien se 
lo puede encontrar como X (X &), que es el constructor de copia de una clase llamada 
X. 

Si crea un constructor de copia, el compilador no realizara una copia bit a bit 
cuando cree un nuevo objeto a partir de otro. El compilador siempre llamara al cons¬ 
tructor de copia. Si no crea el constructor de copia, el compilador intentara hacer 
algo razonable, pero usted tiene la opcion de tener control total del proceso. 

Ahora es posible solucionar el problema en HowMany. cpp: 

//: Cll:HowMany2.cpp 
// The copy-constructor 

#include <fstream> 

#include <string> 

using namespace std; 

ofstream out("HowMany2.out"); 

class HowMany2 { 

string name; // Object identifier 

static int objectCount; 

public: 
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HowMany2 (const strings id = "") : name(id) { 

++objectCount; 
print("HowMany2()") ; 

} 

~HowMany2() { 

—objectCount ; 
print("~HowMany2() ") ; 

} 

// The copy-constructor: 

HowMany2 (const HowMany2& h) : name(h.name) { 
name += " copy"; 

++objectCount; 

print("HowMany2(const HowMany2&)"); 

} 

void print (const strings msg = "") const { 
if (msg.size() != 0) 

out << msg << endl; 
out << ' \t' << name << " 

<< "objectCount = " 

<< objectCount << endl; 


} ; 


int HowMany2::objectCount = 0; 

// Pass and return BY VALUE: 

HowMany2 f(HowMany2 x) { 

x.print("x argument inside f()"); 
out << "Returning from f()" << endl; 

return x; 


int main() { 

HowMany2 h("h" ) ; 

out << "Entering f()" << endl; 

HowMany2 h2 = f(h); 

h2.print("h2 after call to f()"); 

out << "Call f(), no return value" << endl; 

f (h) ; 

out << "After call to f()" << endl; 

} ///:- 


Hay unas cuantas cosas nuevas para que pueda hacerse una idea mejor de lo que 
pasa. Primeramente, el string name hace de identificador de objeto cuando se im- 
prima en la salida. Puede poner un identificador (normalmente el nombre del objeto) 
en el constructor para que se copie en name utilizando el constructor con un string 
como argumento. Por defecto se crea un string vacio. El constructor incrementa ob¬ 
jectCount y el destructor lo disminuye, igual que en el ejemplo anterior. 

Lo siguientees el constructor de copia, HowMany2 (const HowMany2& ). El cons¬ 
tructor de copia simplemente crea un objeto a partir de otro existente, asi que copia 
en name el identificador del objeto origen, seguido de la palabra «copy», y asi puede 
ver de donde precede. Si mira atentamente, vera que la llamada name (h. name) en 
la lista de inicializadores del constructor esta llamando al constructor de copia de la 
clase string. 
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Dentro del constructor de copia, se incrementa el contador igual que en el cons¬ 
tructor normal. Esto quiere decir que obtendra un contador de objetos preciso cuan- 
do pase y retorne por valor. 

La funcion print () se ha modificado para imprimir en la salida un mensaje, 
el identificador del objeto y el contador de objetos. Como ahora accede al atributo 
name de un objeto concreto, ya no puede ser un metodo estatico. 

Dentro de main () puede ver que hay una segunda llama da a f (). Sin embargo 
esta llamada utiliza la caracteristica de C para ignorar el valor de retorno. Pero ahora 
que sabe como se retorna el valor (es decir, codigo dentro de la funcion que maneja el 
proceso de retorno poniendo el resultado en un lugar cuya direccion se pasa como 
un argumento escondido), podria preguntarse que ocurre cuando se ignora el valor 
de retorno. La salida del programa mostrara alguna luz sobre el asunto. 

Pero antes de mostrar la salida, he aqui un pequeno programa que utiliza iost- 
reams para anadir numeros de linea a cualquier archivo: 

//: Cll:Linenum.cpp 
//{T} Linenum.cpp 
// Add line numbers 

#include /require.h" 

#include <vector> 

#include <string> 

#include <fstream> 

#include <iostream> 

#include <cmath> 
using namespace std; 

int main(int argc, char* argv[]) { 

requireArgs(argc, 1, "Usage: linenum file\n" 

"Adds line numbers to file"); 
ifstream in(argv[l]); 
assure(in, argv[l]); 
string line; 
vector<string> lines; 

while (getline(in, line)) // Read in entire file 
lines.push_back(line); 
if (lines.size() == 0) return 0; 
int num = 0; 

// Number of lines in file determines width: 

const int width = 

int(loglO((double)lines.size())) + 1; 
for(int i = 0; i < lines.size(); i++) { 

cout.setf(ios::right, ios::adjustfield); 
cout.width(width) ; 

cout << ++num << ") " << lines[i] << endl; 


} ///:- 


El archivo se pasa a un vector<string>, utilizando el mismo codigo fuente que 
ha visto anteriormente en este libro. Cuando se ponen los numeros de linea, nos 
gustaria que todas las lineas estuvieran alineadas, y esto necesita conocer el numero 
de lineas en el archivo para que sea coherente. Se puede conocer el numero de lineas 
con vector: : size (), pero lo que realmente necesitamos es conocer si hay mas 
lineas de 10, 100, 1000, etc. Si se utiliza el logaritmo en base 10 sobre el numero de 
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lineas en el archivo, se trunca a un entero y se anade uno al valor resultante, eso 
determinara el ancho maximo en digitos que un numero de linea puede tener. 

Notese que hay un par de llamadas extranas dentro del bucle for: setf () y 
width (). Hay llamadas de ostream que permiten controlar, en este caso, la justifi- 
cacion y anchura de la salida. Sin embargo se debe llamar cada vez que se imprime 
linea y por eso estan dentro del bucle for. El Volumen 2 de este libro tiene un ca- 
pitulo entero que explica los iostreams y que cuenta mas sobre estas llamadas as! 
como otras formas de controlar los iostreams. 

Cuando se aplica Linenum. cpp a HowMany2 . out, resulta: 


1) HowMany2() 

2) h: objectCount = 1 

3) Entering f() 

4) HowMany2(const HowMany2&) 

5) h copy: objectCount = 2 

6) x argument inside f() 

7) h copy: objectCount = 2 

8) Returning from f() 

9) HowMany2(const HowMany2&) 

10) h copy copy: objectCount = 3 

11) ~HowMany2() 

12) h copy: objectCount = 2 

13) h2 after call to f() 

14) h copy copy: objectCount = 2 

15) Call f(), no return value 

16) HowMany2(const HowMany2&) 

17) h copy: objectCount = 3 

18) x argument inside f() 

19) h copy: objectCount = 3 

20) Returning from f() 

21) HowMany2(const HowMany2&) 

22) h copy copy: objectCount = 4 

23) ~HowMany2() 

24) h copy: objectCount = 3 

25) ~HowMany2() 

26) h copy copy: objectCount = 2 

27) After call to f() 

28) ~HowMany2() 

29) h copy copy: objectCount = 1 

30) ~HowMany2() 

31) h: objectCount = 0 


Como se esperaba, la primera cosa que ocurre es que para h se llama al construc¬ 
tor normal, el cual incrementa el contador de objetos a uno. Pero entonces, mientras 
se entra en f (), el compilador llama silenciosamente al constructor de copia para ha- 
cer el paso por valor. Se crea un nuevo objeto, que es copia de h (y por tanto tendra 
el identificador «h copy») dentro del ambito de la funcion f () . As! pues, el contador 
de objetos se incrementa a dos, por cortesia del constructor de copia. 

La lmea ocho indica el principio del retorno de f (). Pero antes de que se destruya 
la variable local «h copy» (pues sale de ambito al final de la funcion), se debe copiar 
al valor de retorno, que es h2. Por tanto h2, que no estaba creado previamente, se 
crea de un objeto ya existente (la variable local dentro de f () ) y el constructor de 
copia vuelve a utilizarse en la linea 9. Ahora el identificador de h2 es «h copy copy» 
porque copio el identificador de la variable local de f (). Cuando se devuelve el 
objeto, pero antes de que la funcion termine, el contador de objetos se incrementa 
temporalmente a tres, pero la variable local con identificador «h copy» se destruye, 
disminuyendo a dos. Despues de que se complete la llamada a f () en la linea 13, 
solo hay dos objetos, h y h2, y puede comprobar, de hecho, que h2 termino con el 
identificador «h copy copy». 
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Objetos temporales 

En la linea 15 se empieza la llamada a f ( h ), y esta vez ignora el valor de retorno. 
Puede ver que se invoca el constructor de copia en la linea 16, igual que antes, para 
pasar el argumento. Y tambien, igual que antes, en la linea 21 se llama al constructor 
de copia para el valor de retorno. Pero el constructor de copia necesita una direccion 
para utilizar como destino (es decir, para trabajar con el puntero this). ^De donde 
precede esta direccion? 

Esto prueba que el compilador puede crear un objeto temporal cuando lo necesita 
para evaluar adecuadamente una expresion. En este caso, crea uno que ni siquiera 
se le ve actuar como destino para el valor ignorado retornado por f (). El tiempo 
de vida de este objeto temporal es tan corto como sea posible para que el programa 
no se llene de objetos temporales esperando a ser destruidos, lo cual provocaria la 
utilizacion ineficaz de recursos valiosos. En algunos casos, el objeto temporal podria 
pasarse inmediatamente a otra funcion, pero en este caso no se necesita despues de 
la llamada a la funcion, asi que en cuanto la funcion termina, llamando al destructor 
del objeto local (lineas 23 y 24), el objeto temporal tambien se destruye (lineas 25 y 
26). 

Finalmente, de la linea 28 a la linea 31, se destruye el objeto h2, seguido de h y el 
contador de objetos vuelve a cero. 



11.3.3. El constructor de copia por defecto 

Como el constructor de copia implementa el paso y retorno por valor, es impor- 
tante que el compilador cree uno en el caso de estructuras simples (de hecho, es lo 
mismo que hace C). Sin embargo todo lo que se ha visto es el comportamiento por 
defecto: una copia bit a bit. 

Cuando se utilizan tipos mas complejos, el compilador de C++ creara un cons¬ 
tructor de copia automaticamente si no se implementa explicitamente. De nuevo, 
una copia bit a bit no tiene sentido, porque no tiene porque ser el comportamiento 
que se necesita. 

He aqui un ejemplo para mostrar el comportamiento mas inteligente del com¬ 
pilador. Suponga que crea una nueva clase compuesta por objetos de varias clases 
diferentes. A esto se le denomina composition, y es una de las formas en las que se 
pueden hacer nuevas clases a partir de las ya existentes. Ahora desempene el pa- 
pel de un novato que trata de resolver un problema rapidamente creando una nueva 
clase de esta manera. No sabe nada sobre los constructores de copia, asi que no lo im¬ 
plementa. El ejemplo muestra lo que el compilador hace cuando crea un constructor 
de copia por defecto para su nueva clase: 

//: Cll:DefaultCopyConstructor.cpp 
// Automatic creation of the copy-constructor 
#include <iostream> 

#include <string> 
using namespace std; 

class WithCC { // With copy-constructor 

public: 

// Explicit default constructor required: 

WithCC() {} 

WithCC (const WithCCS) { 

cout << "WithCC(WithCCS)" << endl; 

} 


320 
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class WoCC { // Without copy-constructor 

string id; 

public: 

WoCC(const strings ident = "") : id(ident) {} 

void print (const strings msg = "") const { 
if (msg.size() != 0) cout << msg << 

cout << id << endl; 

} 


class Composite { 

WithCC withcc; // Embedded objects 
WoCC wocc; 

public: 

Composite() : wocc("Composite()") {} 

void print (const strings msg = "") const { 
wocc.print(msg); 


} ; 


int main() { 

Composite c; 

c . print("Contents of c"); 

cout << "Calling Composite copy-constructor" 
<< endl; 

Composite c2 = c; // Calls copy-constructor 

c2.print("Contents of c2"); 

} ///:- 


La clase WithCC contiene un constructor de copia, que simplemente anuncia que 
ha sido llama do, y esto demuestra una cuestion interesante: dentro de la clase C- 
omposite se crea un objeto tipo WithCC utilizando el constructor por defecto. Si 
WithCC no tuviera ningun constructor, el compilador crearia uno por defecto auto- 
maticamente, el cual, en este caso, no haria nada. No obstante, si anade un construc¬ 
tor por defecto, le esta diciendo al compilador que ha de utilizar los constructores 
disponibles, por lo que el no crea ningun constructor por defecto y se quejara a no 
ser que explicitamente cree un constructor por defecto, como se hizo en WithCC. 

La clase WoCC no tiene constructor de copia, pero su constructor almacenara un 
string interno imprimible por la funcion print (). La lista de inicializacion del cons¬ 
tructor (presentado brevemente en el Capitulo 8 y tratado completamente en el Ca- 
pitulo 14) de Composite llama explicitamente a este constructor. La razon de esto 
se vera posteriormente. 

La clase Composite tiene objetos miembro tanto de WithCC como de WoCC (note 
que el objeto interno wocc se inicializa en la lista de inicializadores del constructor de 
Composite, como debe ser), pero no estan inicializados explicitamente en el cons¬ 
tructor de copia. Sin embargo un objeto Composite se crea en main () utilizando el 
constructor de copia: 

Composite c2 = c; 


El compilador ha creado un constructor de copia para Composite automatica- 
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mente, y la salida del programa revela la manera en que se crea: 

Contents of c: Composite() 

Calling Composite copy-constructor 
WithCC(WithCCS) 

Contents of c2: Composite() 


Para la creacion de un constructor de copia para una clase que utiliza compo¬ 
sition (y herencia, que se trata en el Capitulo 14), el compilador llama a todos los 
constructores de copia de todos los miembros objeto y de las clases base de manera 
recursiva. Es decir, si el miembro tambien contiene otro objeto, tambien se llama a 
su constructor de copia. En el ejemplo, el compilador llama al constructor de copia 
de WithCC. La salida muestra que se llama a este constructor. Como WoCC no tiene 
constructor de copia, el compilador crea uno que realiza simplemente una copia bit a 
bit para que el constructor de copia de Composite lo pueda llamar. La llamada a C- 
omposite : : print () en main () muestra que esto ocurre, porque el contenido de 
c2 . wocc es identico al contenido de c . wocc. El proceso que realiza el compilador 
para crear un constructor de copia se denomina initialization de miembros (memberwise 
initialization). 

Se recomienda definir constructor de copia propio en vez de usar el que crea el 
compilador. Eso garantiza que estara bajo su control. 


11.3.4. Alternativas a la construccion por copia 

A estas alturas su cabeza debe estar echando humo, y se preguntara como es 
posible que pudiera escribir una clase que funcionase sin saber nada acerca del cons¬ 
tructor de copia. No obstante, recuerde que el constructor de copia solo es necesario 
cuando la clase se pasa por valor. Si esto no va a ocurrir, entonces no lo necesita. 

Evitando el paso por valor 

«Pero», puede decir, «si no defino el constructor de copia, el compilador lo creara 
por mi. ^Como se que un objeto nunca se pasara por valor?» 

Existe una tecnica simple para evitar el paso por valor: declare un constructor de 
copia private. Ni siquiera necesita definirlo (solo declararlo), a no ser que un me- 
todo o una funcion friend necesite realizar un paso por valor. Si el usuario intenta 
pasar o retornar el objeto por valor, el compilador se quejara con un error porque el 
constructor de copia es privado. El compilador ya no puede crear un constructor de 
copia por defecto porque explicitamente ya hay uno creado. 

He aqui un ejemplo: 

//: Cll:NoCopyConstruction.cpp 
// Preventing copy-construction 

class NoCC { 
int i; 

NoCC (const NoCCS); // No definition 

public: 

NoCC (int ii = 0) : i(ii) {} 

} ; 


void f (NoCC); 
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int main () { 

NoCC n; 

//! f (n); // Error: copy-constructor called 
//! NoCC n2 = n; // Error: c-c called 
//! NoCC n3 (n); // Error: c-c called 
} ///:- 


Note la utilization de la forma mas general 

NoCC(const NoCCS); 

utilizando const 

Funciones que modifican objetos externos 

La sintaxis de referencias es mas agradable que la de punteros, aunque oculte 
significado al que lea el codigo fuente. Por ejemplo, en la libreria iostreams existe 
una version sobrecargada de la funcion get () que tiene como argumento un char 
&, y su cometido es modificar ese argumento y utilizarlo como el valor que retorna 
get (). No obstante, si lee el codigo fuente de esta funcion, no es inmediatamente 
obvio que la variable que se pasa como argumento vaya a ser modificada: 

char c; 
cin.get(c); 

Parece que a la funcion se le pasa por valor, lo que sugiere que el argumento que 
se pasa no se modifica. 

A causa de esto, es probablemente mas seguro, desde el punto de vista de mante- 
nimiento del codigo fuente, utilizar punteros que pasen la direction del argumento 
que se desee modificar. Si siempre pasa direcciones como referencias constantes excep- 
to cuando intenta modificar el argumento que se pasa a traves de la direction, donde 
pasaria un puntero no constante, entonces es mas facil para el lector seguir el codigo 
fuente. 


11.4. Punteros a miembros 

Un puntero es una variable que contiene la direction de alguna ubicacion. Se pue- 
de cambiar a lo que el puntero apunta en tiempo de execution. La ubicacion a la que 
apunta puede ser un dato o funcion. El puntero a miembro de C++ sigue el mismo con- 
cepto, excepto que a lo que apunta es una ubicacion dentro de una clase. Pero surge 
el dilema de que un puntero necesita una direction, pero no hay «direccion» alguna 
dentro de una clase; La selection de un miembro de una clase se realiza mediante un 
desplazamiento dentro de la clase. Pero primero hay que conocer la direction donde 
comienza un objeto en particular para luego sumarle el desplazamiento y asi locali- 
zar el miembro de la clase. La sintaxis de los punteros a miembros requiere que usted 
seleccione un objeto al mismo tiempo que esta accediendo al contenido del puntero 
al miembro. 

Para entender esta sintaxis, considere una estructura simple, con un puntero s - 
p y un objeto so. Puede seleccionar sus miembros de la misma manera que en el 
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siguiente ejemplo: 

//: Cll:SimpleStructure.cpp 

struct Simple { int a; }; 
int main() { 

Simple so, *sp = &so; 

sp->a; 

so. a; 

} ///'.- 


Ahora suponga que tiene un puntero normal que se llama ip y que apunta a un 
entero. Para acceder a lo que apunta ip, ha de estar precedido por un 

*ip=4; 

Finalmente, se preguntara que pasa si tiene un puntero que esta apuntando a 
algo que esta dentro de un objeto, incluso si lo que realmente representa es un des- 
plazamiento dentro del objeto. Para acceder a lo que esta apuntando, debe preceder 
el puntero con Pero como es un desplazamiento dentro de un objeto, tambien ha 
de referirse al objeto con el que estamos tratando. Asi, el * se combina con el objeto. 
Por tanto, la nueva sintaxis se escribe ->* para un puntero que apunta a un objeto, y 
A para un objeto o referencia, tal como esto: 

objectPointer->*pointerToMember = 47; 
object.*pointerToMember = 47; 

Pero, ^cual es la sintaxis para definir el pointerToMember? Pues como cual- 
quier puntero, tiene que decir el tipo al que apuntara, por lo que se utilizaria el en 
la definition. La unica diferencia es que debe decir a que clase de objetos apuntara 
ese atributo puntero. Obviamente, esto se consigue con el nombre de la clase y el 
operador de resolution de ambito. Asi, 

int ObjectClass::*pointerToMember; 


define un atributo puntero llamado pointerToMember que apunta a cualquier 
entero dentro de ObjectClass. Tambien puede inicializar el puntero cuando lo 
defina (o en cualquier otro momento): 

int ObjectClass::*pointerToMember = &ObjectClass::a; 

Realmente no existe una «direccion» de ObjectClass : : a porque se esta refi- 
riendo a la clase y no a un objeto de esa clase. Asi, & Ob jectClass: :a se puede 
utilizar solo con la sintaxis de un puntero a miembro. 

He aqui un ejemplo que muestra como crear y utilizar punteros a atributos: 

//: Cll:PointerToMemberData.cpp 

#include <iostream> 

using namespace std; 

class Data { 
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public: 

int a, b, c; 

void print () const { 

cout << "a = " << a << ", b = " << b 
« ", c = " << c << endl; 


} ; 

int main() { 

Data d, *dp = &d; 

int Data::*pmlnt = &Data::a; 

dp->*pmlnt = 47; 

pmlnt = &Data::b; 

d.*pmlnt = 48; 

pmlnt = SData::c; 

dp->*pmlnt = 49; 

dp->print (); 

} ///:- 


Obviamente, son muy desagradables de utilizar en cualquier lugar excepto para 
caso especiales (que es exactamente para lo que se crearon). 

Ademas, los punteros a miembro son bastante limitados: pueden asignarse so- 
lamente a una ubicacion especifica dentro de una clase. No podria, por ejemplo, 
incrementarlos o compararlos tal como puede hacer con punteros normales. 


11.4.1. Funciones 

Un ejercicio similar se produce con la sintaxis de puntero a miembro para meto- 
dos. Un puntero a una funcion (presentado al final del Capitulo 3) se define como: 

int (*fp) (float); 


Los parentesis que engloban a (* f b) son necesarios para que fuercen la evalua¬ 
tion de la definition apropiadamente. Sin ellos seria una funcion que devuelve un 
int*. 

Los parentesis tambien desempenan un papel importante cuando se definen y 
utilizan punteros a metodos. Si tiene una funcion dentro de una clase, puede definir 
un puntero a ese metodo insertando el nombre de la clase y el operador de resolution 
de ambito en una definition habitual de puntero a funcion: 

//: Cll:PmemFunDefinition.cpp 

class Simple2 { 
public: 

int f(float) const { return 1; } 

} ; 

int (Simple2 : :*fp) (float) const; 

int ( Simple2::*fp2 )(float) const = &Simple2::f; 

int main ( ) { 

fp = &Simple2::f; 
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En la definicion de fp2 puede verse que el puntero a un metodo puede iniciali- 
zarse cuando se crea, o en cualquier otro momenta. A diferencia de las funciones no 
son miembros, el & no es opcional para obtener la direccion de un metodo. Sin em¬ 
bargo, se puede dar el identificador de la funcion sin la lista de argumentos, porque 
la sobrecarga se resuelve por el tipo de puntero a miembro. 


Un ejemplo 

Lo interesante de un puntero es que se puede cambiar el valor del mismo para 
apuntar a otro lugar en tiempo de ejecucion, lo cual proporciona mucha flexibilidad 
en la programacion porque a traves de un puntero se puede cambiar el comporta- 
miento del programa en tiempo de ejecucion. Un puntero a miembro no es distinto; 
le permite elegir un miembro en tiempo de ejecucion. Tipicamente, sus clases so¬ 
lo tendran metodos visibles publicamente (los atributos normalmente se consideran 
parte de la implementacion que va oculta), de modo que el siguiente ejemplo elige 
metodos en tiempo de ejecucion. 


//: Cll:PointerToMemberFunction.cpp 

#include <iostream> 

using namespace std; 


class Widget { 
public: 

void f(int) const { 
void g(int) const { 
void h(int) const { 
void i(int) const { 


cout << 
cout << 
cout << 
cout << 


"Widget: 
"Widget: 
"Widget: 
"Widget: 


f 0 \n"; 
g 0 \n"; 
h() \n"; 
i 0 \n"; 


} 

} 

} 

} 


} ; 


int main() { 

Widget w; 

Widget* wp = &w; 

void (Widget::*pmem) (int) const = &Widget::h; 
(w.*pmem)(1); 

(wp->*pmem)(2); 

} ///:~ 


Por supuesto, no es razonable esperar que el usuario casual cree expresiones tan 
complejas. Si el usuario necesita manipular directamente un puntero a miembro, los 
typedef vienen al rescate. Para dejar aun mejor las cosas, puede utilizar un punte¬ 
ro a funcion como parte del mecanismo interno de la implementacion. He aqui un 
ejemplo que utiliza un puntero a miembro dentro de la clase. Todo lo que el usuario 
necesita es pasar un numero para elegir una funcion. 1 

//: Cll:PointerToMemberFunction2.cpp 

#include <iostream> 

using namespace std; 

class Widget { 

void f(int) const { cout << "Widget ::f ()\n" ; } 

void g(int) const { cout << "Widget::g() \n" ; } 

void h(int) const { cout << "Widget::h() \n" ; } 

void i(int) const { cout << "Widget::i()\n" ; } 


1 Gracias a Owen Mortensen por este ejemplo 
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enum { cnt =4 }; 

void (Widget::*fptr[cnt]) (int) const; 
public: 

Widget() { 


fptr 

0] 

= SWidget: 

:f; // Full spec required 

fptr 

1] 

= SWidget: 

:g; 

fptr 

2] 

= swidget: 

: h; 

fptr 

3] 

= SWidget: 

: i; 


void select (int i, int j) { 

if(i < 0 || i >= cnt) return; 
(this->*fptr [i]) (j) ; 

} 

int count () { return cnt; } 


int main () { 

Widget w; 

for(int i = 0; i < w.count(); f++) 
w.select(i, 47); 

} ///:~ 


En la interfaz de la clase y en main (), puede observar que toda la implemen¬ 
tation, funciones incluidas, es privada. El codigo ha de pedir el count () de las 
funciones. De esta manera, el que implementa la clase puede cambiar la cantidad 
de funciones en la implementation por debajo sin que afecte al codigo que utilice la 
clase. 

La inicializacion de los punteros a miembro en el constructor puede parecer re- 
dundante. ^No deberia ser capaz de poner 

fptr[1] = &g; 

porque el nombre g es un metodo, el cual esta en el ambito de la clase? El pro- 
blema aqui es que no seria conforme a la sintaxis de puntero a miembro. Asi todo el 
mundo, incluido el compilador, puede imaginarse que esta pasando. De igual forma, 
cuando se accede al contenido del puntero a miembro, parece que 


(this->*fptr[i]) (j) ; 


tambien es redundante; this parece redundante. La sintaxis necesita que un 
puntero a miembro siempre este ligado a un objeto cuando se accede al contenido al 
que apunta. 


11.5. Resumen 

Los punteros en C++ son casi identicos a los punteros en C, lo cual es bueno. De 
otra manera, gran cantidad de codigo C no compilaria en C++. Los unicos errores 
en tiempo de compilation seran aquellos que realicen asignaciones peligrosas. Esos 
errores pueden eliminarse con una simple (pero explicito!) molde. 

C++ tambien anade la referenda de Algol y Pascal, que es como un puntero cons- 
tante que el compilador hace que se acceda directamente al contenido al que apunta. 
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Una referenda contiene una direccion, pero se trata como un objeto. Las referencias 
son esenciales para una sintaxis clara con la sobrecarga de operadores (el tema del 
siguiente capitulo), pero tambien proporcionan mejoras sintacticas para el paso y 
retorno de objetos en funciones normales. 

El constructor de copia coge una referenda a un objeto existente del mismo tipo 
que el argumento, y lo utiliza para la creacion de un nuevo objeto a partir del que 
existente. El compilador llama automaticamente al constructor de copia cuando pasa 
o retorna un objeto por valor. Aunque el compilador crea un constructor de copia 
automaticamente, si cree que su clase necesita uno, deberia definirlo para asegurar 
un comportamiento apropiado. Si no desea que el objeto se pase o retorne por valor, 
deberia crear un constructor de copia privado. 

Los punteros a miembro tienen la misma capacidad que los punteros normales: 
puede elegir una region de memoria particular (atributo o metodo) en tiempo de 
ejecucion. Los punteros a miembro funcionan con los miembros de una clase en vez 
de variables o funciones globales. Ofrecen la suficiente flexibilidad para cambiar el 
comportamiento en tiempo de ejecucion. 


11.6. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Convierta el fragmento de codigo «bird & rock» del principio de este capitulo a 
un programa C (utilizando estructuras para los tipos de datos), y que compile. 
Ahora intente compilarlo con un compilador de C++ y vea que ocurre. 

2. Coja los fragmentos de codigo al principio de la seccion titulada «Referencias 
en C++» y pongalos en un main (). Anada sentencias para imprimir en la sali- 
da para que pueda demostrar usted mismo que las referencias son como pun¬ 
teros que se dereferencian automaticamente. 

3. Escriba un programa en el cual intente (1) Crear una referencia que no este 
inicializada cuando se crea. (2) Cambiar una referencia para que se refiera a 
otro objeto despues de que se haya inicializado. (3) Crear una referencia nula. 

4. Escriba una funcion que tome un puntero por argumento, modifique el conte- 
nido de lo que el apunta puntero, y retorne ese mismo contenido como si de 
una referencia se tratara. 

5. Cree una nueva clase con algunos metodos, y haga que el objeto sea apuntado 
por el argumento del Ejercicio 4. Haga que el puntero pasado como argumento 
y algunos metodos sean constantes y pruebe que solo puede llamar a los me¬ 
todos constantes dentro de su funcion. Haga que el argumento de su funcion 
sea una referencia en vez de un puntero. 

6. Coja los fragmentos de codigo al principio de la seccion «referencias a puntero» 
y conviertalos en un programa. 

7. Cree una funcion que tome como argumento una referencia a un puntero que 
apunta a otro puntero y modifique ese argumento. En main (), llame a la fun¬ 
cion. 
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8. Cree una funcion que toma un argumento del tipo char& y lo modifica. En 
el main ( ) imprima a la salida una variable char, llame a su funcion con esa 
variable e imprima la variable de nuevo para demostrar que ha sido cambiada. 
^Como afecta esto a la legibilidad del programa? 

9. Escriba una clase que tiene un metodo constante y otra que no lo tiene. Escriba 
tres funciones que toman un objeto de esa clase como argumento; la primera lo 
toma por valor, la segunda lo toma por referenda y la tercera lo toma median- 
te una referenda constante. Dentro de las funciones, intente llamar a las dos 
funciones de su clase y explique los resultados. 

10. (Algo dificil) Escriba una funcion simple que toma un entero como argumento, 
incrementa el valor, y lo retorna. En main () , llame a su funcion. Intente que 
el compilador genere el codigo ensamblador e intente entender como los ar- 
gumentos se pasan y se retornan, y como las variables locales se colocan en la 
pila. 

11. Escriba una funcion que tome como argumentos un char, int, float y double. 
Genere el codigo ensamblador con su compilador y busque las instrucciones 
que apilan los argumentos en la pila antes de efectuar la llamada a funcion. 

12. Escriba una funcion que devuelva un double. Genere el codigo ensamblador y 
explique como se retorna el valor. 

13. Genere el codigo ensamblador de PassingBigStructures . cpp. Recorra y 
desmitifique la manera en que su compilador genera el codigo para pasar y 
devolver estructuras grandes. 

14. Escriba una simple funcion recursiva que disminuya su argumento y retorne 
cero si el argumento llega a cero, o en otro caso que se llame a si misma. Genere 
el codigo ensamblador para esta funcion y explique la forma en el compilador 
implementa la recurrencia. 

15. Escriba codigo para demostrar que el compilador genera un constructor de co- 
pia automaticamente en caso de que no lo haga el programador. Demuestre 
que el constructor de copia generado por el compilador realiza una copia bit a 
bit de tipos primitivos y llama a los constructores de copia de los tipos defini- 
dos por el usuario. 

16. Escriba una clase en la que el constructor de copia se anuncia a si mismo a 
traves de cout. Ahora cree una funcion que pasa un objeto de su nueva clase 
por valor y otra mas que crea un objeto local de su nueva clase y lo devuelve 
por valor. Llame a estas funciones para demostrar que el constructor de copia 
es, en efecto, llamado cuando se pasan y retornan objetos por valor. 

17. Cree un objeto que contenga un double*. Que el constructor inicialice el dou¬ 
ble* llamando a new double y asignando un valor. Entonces, que el destruc¬ 
tor imprima el valor al que apunta, asigne ese valor a -1, llame a delete para 
liberar la memoria y ponga el puntero a cero. Ahora cree una funcion que to¬ 
me un objeto de su clase por valor, y llame a esta funcion desde main (). ^Que 
ocurre? Solucione el problema escribiendo un constructor de copia. 

18. Cree una clase con un constructor que parezca un constructor de copia, pero 
que tenga un argumento adicional con un valor por defecto. Muestre que a 
pesar de eso se utiliza como constructor de copia. 
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19. Cree una clase con un constructor de copia que se anuncie a si mismo (es decir 
que imprima por la salida que ha sido llamado). Haga una segunda clase que 
contenga un objeto miembro de la primera clase, pero no cree un constructor 
de copia. Demuestre que el constructor de copia, que genera automaticamente 
el compilador en la segunda clase, llama al constructor de copia de la primera. 

20. Cree una clase muy simple, y una funcion que devuelva un objeto de esa clase 
por valor. Cree una segunda funcion que tome una referenda de un objeto de 
su clase. Llame a la segunda funcion pasandole como argumento una llamada 
a la primera funcion, y demuestre que la segunda funcion debe utilizar una 
referenda constante como argumento. 

21. Cree una clase simple sin constructor de copia, y una funcion simple que tome 
un objeto de esa clase por valor. Ahora cambie su clase anadiendole una decla¬ 
ration (solo declare, no defina) privada de un constructor de copia. Explique 
lo que ocurre cuando compila la funcion. 

22. Este ejercicio crea una alternativa a la utilization del constructor de copia. Cree 
una clase X y declare (pero no defina) un constructor de copia privado. Haga 
una funcion clone () publica como un metodo constante que devuelve una 
copia del objeto creado utilizando new. Ahora escriba una funcion que tome 
como argumento un const X& y clone una copia local que puede modificarse. 
El inconveniente de esto es que es el programador el responsable de destruir 
explicitamente el objeto clonado (utilizando delete) cuando haya terminado 
con el. 

23. Explique que esta mal en Mem. cpp y MemTest. cpp del Capitulo 7. Solucione 
el problema. 

24. Cree una clase que contenga un double y una funcion print () que imprima el 
double. Cree punteros a miembro tanto para el atributo como al metodo de su 
clase. Cree un objeto de su clase y un puntero a ese objeto, y manipule ambos 
elementos de la clase a traves de los punteros a miembro, utilizando tanto el 
objeto como el puntero al objeto. 

25. Cree una clase que contenga un array de enteros. ^Puede recorrer el array me- 
diante un puntero a miembro? 

26. Modifique PmemFunDef inition . cpp anadiendo un metodo f () sobrecar- 
gado (puede determinar la lista de argumentos que cause la sobrecarga). Aho¬ 
ra cree un segundo puntero a miembro, asignelo a la version sobrecargada de 
f (), y llame al metodo a traves del puntero. ^Como sucede la resolution de la 
funcion sobrecargada en este caso? 

27. Empiece con la funcion FunctionTable . cpp del Capitulo 3. Cree una clase 
que contenga un vector de punteros a funciones, con metodos add () y remo¬ 
ve () para anadir y quitar punteros a funcion. Anada una funcion denominada 
run () que recorra el vector y llame a todas la funciones. 

28. Modifique el Ejercicio 27 para que funcione con punteros a metodos. 
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12: Sobrecarga de operadores 

La sobrecarga de operadores es solamente «azucar sintactico», lo 
que significa que es simplemente otra manera de invocar funciones. 

La diferencia es que los argumentos para estas funciones no aparecen entre pa- 
rentesis, sino que rodean o siguen a los caracteres que siempre penso como opera¬ 
dores inalterables. 

Hay dos diferencias entre el uso de un operador y el de una llamada a funcion 
normal. La sintaxis es diferente: un operador es a menudo «llamado» situandolo 
entre (o despues de) los argumentos. La segunda diferencia es que el compilador 
determina que «funcion» llamar. Por ejemplo, si esta usando el operador + con ar¬ 
gumentos de punto flotante, el compilador «llama» a la funcion para realizar una 
suma de punto flotante (esta «llamada» normalmente consiste en insertar codigo en 
linea, o una instruccion de punto flotante del procesador). Si usa el operador + con 
un numero de punto flotante y un entero, el compilador «llama» a una funcion espe¬ 
cial para convertir el int a un float,y entonces «llama» a la funcion de suma en punto 
flotante. 

Sin embargo, en C++ es posible definir nuevos operadores que trabajen con cla- 
ses. Esta definicion es exactamente como la definicion de una funcion ordinaria, ex- 
cepto que el nombre de la funcion consiste en la palabra reservada operator se- 
guida del operador. Siendo esta la unica diferencia, el operador se convierte en una 
funcion como otra cualquiera que el compilador llama cuando ve el prototipo ade- 
cuado. 


12.1. Precaucion y tranquilidad 

Es tentador convertirse en un super-entusiasta de la sobrecarga de operadores. 
Son un juguete divertido, al principio. Pero recuerde que es solo un endulzamiento 
sintactico, otra manera de llamar a una funcion. Mirandolo desde esa perspectiva, 
no hay razon para sobrecargar un operador excepto si eso hace al codigo implicado 
con la clase mas sencillo e intuitivo de escribir y especialmente de leer. (Recuerde, el 
codigo se lee mucho mas que se escribe). Si este no es el caso no se moleste. 

Otra reaccion cmun frente al uso de la sobrecarga de operadores es el panico: 
de repente, los operadores de C pierden su significa do familiar.«jTodo ha cambiado 
y mi codigo C por completo hara cosas diferentes!». Esto no es verdad. Todos los 
operadores usados en expresiones que contienen solo tipos de datos incorporados 
no pueden ser cambiados. Nunca podra sobrecargar operadores asi: 

1 « 4; 
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para que se comporten de forman diferente, o que 

1.414 << 2; 

tenga significado. Solo una expresion que contenga tipos de datos definidos por 
el usuario podra tener operadores sobrecargados. 



12.2. Sintaxis 

Definir un operador sobrecargado es como definir una funcion, pero el nombre 
de esa funcion es ope rat or @ en la que @ representa el operador que esta siendo 
sobrecargado. El numero de argumentos en la lista de argumentos del operador so¬ 
brecargado depende de dos factores: 

1. Si es un operador unario (un argumento) o un operador binario (dos argumen¬ 
tos) 

2. Si el operador esta definido como una funcion global (un argumento para los 
unarios, dos para los binarios) o un metodo (cero argumentos para los unarios 
y uno para los binarios. En este ultimo caso el objeto (this) se convierte en el 
argumento del lado izquierdo al operador). 

He aqul una pequena clase que muestra la sintaxis de la sobrecarga de operado¬ 
res: 

//: C12:OperatorOverloadingSyntax.cpp 

#include <iostream> 

using namespace std; 

class Integer { 
int i; 
public: 

Integer (int ii) : i(ii) {} 
const Integer 

operator!(const Integers rv) const { 

cout << "operator!" << endl; 
return Integer (i t rv.i); 

} 

Integers 

operator!=(const Integers rv) { 
cout << "operator!=" << endl; 
i != rv.i; 

return *this; 

} 

} ; 

int main () { 

cout << "built-in types:" << endl; 
int i = l, j=2, k = 3; 
k != i ! j; 

cout << "user-defined types:" << endl; 

Integer ii(l), jj(2), kk(3); 
kk != ii ! jj; 

} ///:~ 
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Los dos operadores sobrecargados estan definidos como metodos en linea que 
imprimen un mensaje al ser llamados. El unico argumento de estas funciones miem- 
bro sera el que aparezca del lado derecho del operador binario. Los operadores una- 
rios no tienen argumentos cuando se definen como metodos. El metodo es invocado 
por el objeto de la parte izquierda del operador. 

Para los operadores incondicionales (los condicionales generalmente devuelven 
un valor booleano), generalmente se deseara devolver un objeto o una referenda del 
mismo tipo que esta operando, si los dos argumentos son del mismo tipo. (Si no son 
del mismo tipo, la interpretation de lo que deberia pasar es responsabilidad suya). 
De esta manera, se pueden construir expresiones tan complicadas como la siguiente: 

kk += ii + jj; 

La expresion operator+ crea un nuevo objeto Integer (un temporario) que 
se usa como argumento rv para el operador operator+=. Este objeto temporal se 
destruye tan pronto como deja de necesitarse. 


12.3. Operadores sobrecargables 

Aunque puede sobrecargar casi todos los operadores disponibles en C, el uso de 
operadores sobrecargados es bastante restrictive. En particular, no puede combinar 
operadores que actualmente no tienen significado en C (como * * para representar la 
potencia), no puede cambiar la precedencia de evaluacion de operadores, y tampoco 
el numero de argumentos requeridos por un operador. Estas restricciones existen 
para prevenir que la creacion de nuevos operadores ofusquen el significado en lugar 
de clarificarlo. 

Las siguientes dos subsecciones muestran ejemplos de todos los operadores nor- 
males, sobrecargados en la forma habitual. 


12.3.1. Operadores unarios 

El siguiente ejemplo muestra la sintaxis para sobrecargar todos los operadores 
unarios, en ambas formas: como funciones globales (funciones friend, no metodos) 
y como metodos. Estas expandiran la clase Integer vista previamente y anadira 
una nueva clase byte. El significado de sus operadores particulares dependera de la 
forma en que los use, pero considere a los programadores del grupo antes de hacer 
algo inesperado. He aqui un catalogo de todas las funciones unarias: 

// : C12:OverloadingUnaryOperators.epp 

#include <iostream> 

using namespace std; 

// Non-member functions: 

class Integer { 
long i; 

Integer* This() { return this; } 
public: 

Integer (long 11 = 0) : i(ll) {} 

//No side effects takes constS argument: 
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friend const Integers 

operator!(const Integers a); 
friend const Integer 

operator-(const Integers a); 
friend const Integer 

operator-(const Integers a) ; 
friend Integer* 

operators (Integers a) ; 
friend int 

operator!(const Integers a); 

// Side effects have non-constS argument: 

// Prefix: 

friend const Integers 
operator+t (Integers a); 

// Postfix: 

friend const Integer 

operator!! (Integers a, int); 

// Prefix: 

friend const Integers 
operator —(Integers a); 

// Postfix: 

friend const Integer 

operator —(Integers a, int); 

} ; 

// Global operators: 

const Integers operator!(const Integers a) { 
cout << "!Integer\n"; 

return a; // Unary ! has no effect 

} 

const Integer operator-(const Integers a) { 
cout << "-Integer\n" ; 
return Integer (-a.i); 

} 

const Integer operator-(const Integers a) { 
cout << "~Integer\n"; 
return Integer (-a.i); 

} 

Integer* operators (Integers a) { 
cout << "SInteger\n"; 
return a.ThisO; // Sa is recursive! 

} 

int operator!(const Integers a) { 
cout << "!Integer\n"; 
return !a.i; 

} 

// Prefix; return incremented value 

const Integers operator!! (Integers a) { 
cout << "!!Integer\n" ; 
a.it!; 

return a; 

} 

// Postfix; return the value before increment: 

const Integer operator!! (Integers a, int) { 
cout << "Integer!!\n"; 

Integer before (a.i); 
a.it!; 

return before; 
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} 

// Prefix; return decremented value 

const Integers operator —(Integers a) { 
cout << "—Integer\n"; 
a . i —; 

return a; 

} 

// Postfix; return the value before decrement: 

const Integer operator —(Integers a, int) { 
cout << "Integer—\n"; 

Integer before(a.i); 
a . i —; 

return before; 


// Show that the overloaded operators work: 
void f (Integer a) { 

+a; 

-a; 

~a; 

Integer* ip = Sa; 

! a; 

++a; 
a+ +; 

— a; 
a—; 

} 


// Member functions (implicit "this"): 

class Byte { 

unsigned char b; 
public: 

Byte (unsigned char bb = 0) : b (bb) {} 

// No side effects: const member function: 

const Bytes operator!() const { 

cout << "+Byte\n"; 

return *this; 

} 

const Byte operator-() const { 

cout << "-Byte\n"; 
return Byte(-b); 

) 

const Byte operator- () const { 

cout << "~Byte\n"; 
return Byte(-b); 

) 

Byte operator! () const { 

cout << "!Byte\n"; 
return Byte(!b); 

} 

Byte* operators () { 

cout << "SByte\n"; 

return this; 

} 

// Side effects: non-const member function: 
const Bytes operator++() { // Prefix 
cout << "++Byte\n"; 
b++; 
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return *this; 

} 

const Byte operator++(int) { // Postfix 
cout << "Byte++\n"; 

Byte before(b); 
b++; 

return before; 

} 

const Bytes operator —() { // Prefix 

cout << "—Byte\n"; 

—b; 

return *this; 

} 

const Byte operator—(int) { // Postfix 
cout << "Byte—\n"; 

Byte before(b); 

—b; 

return before; 



void g(Byte b) { 
+b; 

-b; 

~b; 

Byte* bp = Sb; 
!b; 

++b; 
b+ +; 

—b; 
b—; 

) 


int main () { 

Integer a; 
f (a) ; 

Byte b; 
g (b) ; 

} ///:~ 


Las funciones estan agrupadas de acuerdo a la forma en que se pasan los argu- 
mentos. Mas tarde se daran unas cuantas directrices de como pasar y devolver argu- 
mentos. Las clases expuestas anteriormente (y las que siguen en la siguiente seccion) 
son las tipicas, as! que empiece con ellas como un patron cuando sobrecargue sus 
propios operadores. 

Incremento y decremento 

Los operadores de incremento++ y de decremento — provocan un conflicto por- 
que querra ser capaz de llamar diferentes funciones dependiendo de si aparecen an¬ 
tes (prefijo) o despues (postfijo) del objeto sobre el que actuan. La solucion es simple, 
pero la gente a veces lo encuentra un poco confusa inicialmente. Cuando el compi- 
lador ve, por ejemplo, ++a (un pre-incremento), genera una llamada al operator- 
++ (a) pero cuando ve a++, genera una llamada a operator++ (a, int) . Asi es 
como el compilador diferencia entre los dos tipos, generando llamadas a funciones 
sobrecargadas diferentes. En OverloadingUnaryOperators . cpp para la version 
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de funciones miembro, si el compilador ve ++b, genera una llamada a B : : operat- 
or++ () y si ve b++genera una llamada a B : : operator++ (int). 

Todo lo que el usuario ve es que se llama a una funcion diferente para las ver- 
siones postfija y prefija. Internamente, sin embargo, las dos llamadas de funciones 
tienen diferentes firmas, asi que conectan con dos cuerpos diferentes. El compilador 
pasa un valor constante ficticio para el argumento int (el cual nunca se proporcio- 
nada por un identificador porque el valor nunca se usa) para generar las diferentes 
firmas para la version postfija. 


12.3.2. Operadores binarios 

Los siguientes listados repiten el ejemplo de OverloadingUnaryOperators . 
cpp para los operadores binarios presentandole un ejemplo de todos los operadores 
que pueda querer sobrecargar. De nuevo se muestran ambas versiones, la global y la 
de metodo. 

//: C12:Integer . h 

// Non-member overloaded operators 

#ifndef INTEGER_H 
#define INTEGER_H 
#include <iostream> 

// Non-member functions: 

class Integer { 
long i; 
public: 

Integer (long 11 = 0) : i(ll) {} 

// Operators that create new, modified value: 

friend const Integer 

operator!(const Integers left, 

const Integers right); 
friend const Integer 

operator-(const Integers left, 

const Integers right); 
friend const Integer 

operator* (const Integers left, 

const Integers right); 
friend const Integer 

operator/(const Integers left, 

const Integers right); 
friend const Integer 

operator %(const Integers left, 

const Integers right); 
friend const Integer 

operator A (const Integers left, 

const Integers right); 
friend const Integer 

operators(const Integers left, 

const Integers right); 
friend const Integer 

operator | (const Integers left, 

const Integers right); 
friend const Integer 

operator<<(const Integers left, 

const Integers right); 
friend const Integer 
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operator>>(const Integers left, 

const Integers right); 

// Assignments modify S return lvalue: 
friend Integers 

operator+= (Integers left, 

const Integers right); 
friend Integers 

operator-= (Integers left, 

const Integers right); 
friend Integers 

operator*= (Integers left, 

const Integers right); 
friend Integers 

operator/= (Integers left, 

const Integers right) ; 
friend Integers 

operator %=(Integers left, 

const Integers right) ; 
friend Integers 

operator A =(Integers left, 

const Integers right); 
friend Integers 

operators= (Integers left, 

const Integers right); 
friend Integers 

operator j=(Integers left, 

const Integers right); 
friend Integers 

operator>>= (Integers left, 

const Integers right); 
friend Integers 

operator<<= (Integers left, 

const Integers right); 

// Conditional operators return true/false: 
friend int 

operator==(const Integers left, 

const Integers right) ; 

friend int 

operator != (const Integers left, 

const Integers right); 

friend int 

operator<(const Integers left, 

const Integers right); 

friend int 

operator>(const Integers left, 

const Integers right); 

friend int 

operator<=(const Integers left, 

const Integers right); 

friend int 

operator>=(const Integers left, 

const Integers right); 

friend int 

operators S (const Integers left, 

const Integers right); 

friend int 

operator || (const Integers left, 

const Integers right); 
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// Write the contents to an ostream: 

void print(std::ostrearaS os) const { os << i; } 

} ; 

#endif // INTEGER_H ///:- 


//: C12:Integer.cpp {0} 

// Implementation of overloaded operators 

#include "Integer.h" 

#include /require.h" 

const Integer 

operator!(const Integers left, 

const Integers right) { 
return Integer(left.i + right.i); 

} 

const Integer 

operator-(const Integers left, 

const Integers right) { 
return Integer(left.i - right.i); 

} 

const Integer 

operator*(const Integers left, 

const Integers right) { 
return Integer(left.i * right.i); 

} 

const Integer 

operator/(const Integers left, 

const Integers right) { 
require(right.i != 0, "divide by zero"); 
return Integer(left.i / right.i); 

) 

const Integer 

operator %(const Integers left, 

const Integers right) { 
require(right.i != 0, "modulo by zero"); 
return Integer(left.i % right.i); 

} 

const Integer 

operator"(const Integers left, 

const Integers right) { 
return Integer (left.i A right.i); 

} 

const Integer 

operators(const Integers left, 

const Integers right) { 
return Integer(left.i S right.i); 

) 

const Integer 

operator|(const Integers left, 

const Integers right) { 
return Integer (left.i | right.i); 

} 

const Integer 

operator«(const Integers left, 

const Integers right) { 
return Integer(left.i << right.i); 
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const Integer 

operator»(const Integers left, 

const Integers right) { 
return Integer (left.i >> right.i); 

) 

// Assignments modify S return lvalue: 

Integers operator+= (Integers left, 

const Integers right) { 
if(Sleft == Sright) {/* self-assignment */} 
left.i += right.i; 
return left; 

} 

Integers operator-= (Integers left, 

const Integers right) { 
if(Sleft == Sright) {/* self-assignment */} 
left.i -= right.i; 
return left; 

} 

Integers operator*= (Integers left, 

const Integers right) { 
if(Sleft == Sright) {/* self-assignment */} 
left.i *= right.i; 
return left; 

) 

Integers operator/= (Integers left, 

const Integers right) { 
require(right.i != 0, "divide by zero"); 
if(Sleft == Sright) {/* self-assignment */} 
left.i /= right.i; 
return left; 

} 

Integers operator %=(Integers left, 

const Integers right) { 
require(right.i != 0, "modulo by zero"); 
if(Sleft == Sright) {/* self-assignment */} 
left.i %= right.i; 
return left; 

} 

Integers operator A =(Integers left, 

const Integers right) { 
if(Sleft == Sright) {/* self-assignment */} 
left.i A = right.i; 
return left; 

} 

Integers operators= (Integers left, 

const Integers right) { 
if(Sleft == Sright) {/* self-assignment */} 
left.i S= right.i; 
return left; 

} 

Integers operator !=(Integers left, 

const Integers right) { 
if(Sleft == Sright) {/* self-assignment */} 

left.i |= right.i; 
return left; 


Integers operator>>=(Integers left, 
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const Integers right) { 
if (Sleft == Sright) {/* self-assignment */} 
left.i >>= right.i; 
return left; 

} 

Integers operator<<= (Integers left, 

const Integers right) { 
if (Sleft == Sright) {/* self-assignment */} 
left.i <<= right.i; 
return left; 

} 

// Conditional operators return true/false: 

int operator==(const Integers left, 

const Integers right) $ 
return left.i == right.i; 

} 

int operator!=(const Integers left, 

const Integers right) { 
return left.i != right.i; 

} 

int operator< (const Integers left, 

const Integers right) { 
return left.i < right.i; 

} 

int operator> (const Integers left, 

const Integers right) { 
return left.i > right.i; 

} 

int operator<=(const Integers left, 

const Integers right) { 
return left.i <= right.i; 

} 

int operator>=(const Integers left, 

const Integers right) { 
return left.i >= right.i; 

} 

int operators S (const Integers left, 

const Integers right) { 
return left.i SS right.i; 

} 

int operator || (const Integers left, 

const Integers right) { 
return left.i || right.i; 

} ! / / : ~ 


//: C12:IntegerTest.cpp 
//{L} Integer 

#include "Integer.h" 

#include <fstream> 

using namespace std; 

ofstream out("IntegerTest.out") ; 

void h (Integers cl, Integers c2) { 

// A complex expression: 
cl += cl * c2 + c2 % cl; 
fdefine TRY(OP) \ 
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out << "cl = cl.print(out) ; \ 
out << ", c2 = c2.print (out); \ 
out << "; cl " #OP " c2 produces \ 
(cl OP c2).print(out); \ 
out << endl; 

TRY(+) TRY(—) TRY(*) TRY(/) 

TRY(%) TRY( A ) TRY(&) TRY(|) 

TRY(<<) TRY(>>) TRY(+ =) TRY(-=) 

TRY(*=) TRY(/=) TRY(%=) TRY( A =) 

TRY (& = ) TRY ( | = ) TRY (>> = ) TRY(« = ) 

// Conditionals: 

#define TRYC(OP) \ 

out << "cl = cl.print(out) ; \ 
out << ", c2 = c2.print(out); \ 
out << cl " #OP " c2 produces \ 

out << (cl OP c2); \ 
out << endl; 

TRYC(<) TRYC(>) TRYC(==) TRYC(!=) TRYC(<=) 
TRYC(>=) TRYC(S S ) TRYC(II) 


int main() { 

cout << "friend functions" << endl; 
Integer cl(47), c2(9); 
h(cl, c2); 

} ///:~ 


//: C12:Byte.h 

// Member overloaded operators 

#ifndef BYTE_H 
#define BYTE_H 
#include /require.h" 

#include <iostream> 

// Member functions (implicit "this"): 

class Byte { 

unsigned char b; 
public: 

Byte (unsigned char bb = 0) : b(bb) {} 

// No side effects: const member function: 

const Byte 

operatorf(const Bytes right) const { 
return Byte(b + right.b); 

} 

const Byte 

operator-(const Bytes right) const { 
return Byte(b - right.b); 

} 

const Byte 

operator*(const Bytes right) const { 
return Byte(b * right.b); 

} 

const Byte 

operator/(const Bytes right) const { 
require(right.b != 0, "divide by zero"); 
return Byte(b / right.b); 

} 
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const Byte 

operator %(const Bytes right) const { 
require(right.b != 0, "modulo by zero"); 
return Byte(b % right.b); 

} 

const Byte 

operator A (const Bytes right) const { 
return Byte(b A right.b); 

} 

const Byte 

operators (const Bytes right) const { 
return Byte(b S right.b); 

} 

const Byte 

operator | (const Bytes right) const { 
return Byte(b I right.b); 

) 

const Byte 

operator<<(const Bytes right) const { 
return Byte(b << right.b); 

} 

const Byte 

operator>>(const Bytes right) const { 
return Byte(b >> right.b); 

} 

// Assignments modify S return lvalue. 

// operator= can only be a member function: 

Bytes operator=(const Bytes right) { 

// Handle self-assignment: 

if(this == Sright) return *this; 

b = right.b; 

return *this; 

} 

Bytes operator+=(const Bytes right) { 

if(this == Sright) {/* self-assignment */} 

b += right.b; 

return *this; 

} 

Bytes operator-=(const Bytes right) { 

if(this == Sright) {/* self-assignment */} 

b -= right.b; 

return *this; 

} 

Bytes operator*=(const Bytes right) { 

if(this == Sright) {/* self-assignment */} 

b *= right.b; 

return *this; 

} 

Bytes operator/=(const Bytes right) { 

require(right.b != 0, "divide by zero"); 
if(this == Sright) {/* self-assignment */} 

b /= right.b; 

return *this; 

} 

Bytes operator %= (const Bytes right) { 

require(right.b != 0, "modulo by zero"); 

if(this == Sright) {/* self-assignment */} 
b %= right.b; 
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return *this; 

} 

Byte& operator A =(const Bytes right) { 

if(this == Sright) {/* self-assignment */} 

b A = right.b; 

return *this; 

} 

Bytes operators=(const Bytes right) { 

if(this == Sright) {/* self-assignment */} 

b S= right.b; 

return *this; 

} 

Bytes operator != (const Bytes right) { 

if(this == Sright) {/* self-assignment */} 

b |= right.b; 

return *this; 

} 

Bytes operator»= (const Bytes right) { 

if(this == Sright) {/* self-assignment */} 

b >>= right.b; 

return *this; 

} 

Bytes operator«= (const Bytes right) { 

if(this == Sright) {/* self-assignment */} 

b <<= right.b; 

return *this; 

} 

// Conditional operators return true/false: 

int operator==(const Bytes right) const { 
return b == right.b; 

} 

int operator != (const Bytes right) const { 
return b != right.b; 

} 

int operator<(const Bytes right) const { 
return b < right.b; 

} 

int operator>(const Bytes right) const { 
return b > right.b; 

} 

int operator<=(const Bytes right) const { 
return b <= right.b; 

} 

int operator>=(const Bytes right) const { 
return b >= right.b; 

} 

int operatorSS(const Bytes right) const { 
return b SS right.b; 

} 

int operator || (const Bytes right) const { 
return b I| right.b; 

} 

// Write the contents to an ostream: 

void print(std::ostreamS os) const { 

os << "Ox" << std::hex << int (b) << std::dec; 

} 

} ; 

#endif // BYTE_H ///:- 
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//: C12:ByteTest.cpp 

#include "Byte.h" 

#include <fstream> 

using namespace std; 

ofstream out("ByteTest.out") ; 

void k (Bytes bl. Bytes b2) { 

bl = bl * b2 + b2 % bl; 

idefine TRY2(OP) \ 

out << "bl = bl.print (out); \ 
out << ", b2 = b2.print (out); \ 
out << "; bl " #OP " b2 produces \ 

(bl OP b2).print(out); \ 
out << endl; 

bl = 9; b2 = 47; 

TRY2(+) TRY2(-) TRY2(*) TRY2(/) 

TRY2(%) TRY2( A ) TRY2(S) TRY2(|) 

TRY2(<<) TRY2(>>) TRY2(+=) TRY2(-=) 

TRY2(*=) TRY2(/=) TRY2(%=) TRY2( A =) 

TRY2 (S = ) TRY2 ( | =) TRY2(>>=) TRY2(«=) 

TRY2(=) // Assignment operator 

// Conditionals: 

idefine TRYC2(OP) \ 

out << "bl = "; bl.print (out); \ 
out << ", b2 = "; b2.print (out); \ 
out << "; bl " #OP " b2 produces "; \ 
out << (bl OP b2); \ 
out << endl; 

bl = 9; b2 = 47; 

TRYC2(<) TRYC2(>) TRYC2(==) TRYC2(!=) TRYC2(<=) 
TRYC2(>=) TRYC2(S S) TRYC2(I I ) 

// Chained assignment: 

Byte b3 = 92; 
bl = b2 = b3; 


int main() { 

out << "member functions:" << endl; 
Byte bl(47) , b2 (9); 
k(bl, b2) ; 

} ///:~ 


Puede ver que operator = solo puede ser un metodo. Esto se explica despues. 

Fijese que todos los operadores de asignacion tienen codigo para comprobar la 
auto asignacion; esta es una directiva general. En algunos casos esto no es necesario; 
por ejemplo, con operator+= a menudo querra decir A += A y sumar A a si mis- 
mo. El lugar mas importante para situar las comprobaciones para la auto asignacion 
es operator= porque con objetos complicados pueden ocurrir resultados desastro- 
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sos. (En algunos casos es correcto, pero siempre deberia tenerlo en mente cuando 
escriba operator=). 

Todos los operadores mostrados en los dos ejemplos previos son sobrecargados 
para manejar un tipo simple. Tambien es posible sobrecargar operadores para mane- 
jar tipos compuestos, de manera que pueda sumar manzanas a naranjas, por ejem- 
plo. Antes de que empiece una sobrecarga exhaustiva de operadores, no obstante, 
deberia mirar la seccion de conversion automatica de tipos mas adelante en este ca¬ 
pitulo. A menudo, una conversion de tipos en el lugar adecuado puede ahorrarle un 
monton de operadores sobrecargados. 


12.3.3. Argumentos y valores de retorno 

Puede parecer unpoco confuso inicialmente cuando lea los archivos OverloadingUnaryOperators . 
cpp. Integer . h y Byte . h y vea todas las maneras diferentes en que se pasany de- 
vuelven los argumentos. Aunque usted pueda pasar y devolver argumentos de la 
forma que prefiera, las decisiones en estos ejemplos no se han realizado al azar. Si- 
guen un patron logico, el mismo que querra usar en la mayoria de sus decisiones. 

1. Como con cualquier argumento de funcion, si solo necesita leer el argumento 
y no cambiarlo, lo usual es pasarlo como una referenda const. Normalmen- 
te operaciones aritmeticas (como + y -, etc.) y booleanas no cambiaran sus 
argumentos, asi que pasarlas como una referenda const es lo que vere mayo- 
ritariamente. Cuando la funcion es un metodo, esto se traduce en una metodo 
const. Solo con los operadores de asignacion (como +=) y operators que 
cambian el argumento de la parte derecha, no es el argumento derecho una 
constante, pero todavia se pasa en direction porque sera cambiado. 

2. El tipo de valor de retorno que debe seleccionar depende del significado es- 
perado del operador. (Otra vez, puede hacer cualquier cosa que desee con los 
argumentos y con los valores de retorno). Si el efecto del operador es producir 
un nuevo valor, necesitara generar un nuevo objeto como el valor de retorno. 

Por ejemplo. Integer: : operator! debe producir un objeto Integer que 
es la suma de los operandos. Este objeto se devuelve por valor como una cons¬ 
tante asi que el resultado no se puede modificar como un «valor izquierdo». 

3. Todas los operadores de asignacion modifican el valor izquierdo. Para permitir 
que el resultado de la asignacion pueda ser usado en expresiones encadenadas, 
como a = b = c, se espera que devuelva una referencia al mismo valor iz¬ 
quierdo que acaba de ser modificado. Pero ^deberia ser esta referencia const 
o no const?. Aunque lea a = b = c de izquierda a derecha, el compilador la 
analiza de derecha a izquierda, asi que no esta obligado a devolver una referen¬ 
cia no const para soportar asignaciones encadenadas. Sin embargo, la gente 
a veces espera ser capaz de realizar una operation sobre el elemento de acaba 
de ser asignado, como (a = b) . func () ; para llamar a func de a despues 
de asignarle b. De ese modo, el valor de retorno para todos los operadores de 
asignacion deberia ser una referencia no const para el valor izquierdo. 

4. Para los operadores logicos, todo el mundo espera obtener en el peor de los 
casos un tipo int, y en el mejor un tipo bool. (Las librerias desarrolladas antes 
de que los compiladores de C++ soportaran el tipo incorporado bool usaban 
un tipo int o un typedef equivalente). 

Los operadores de incremento y decremento presentan un dilema a causa de las 
versiones postfija y prefija. Ambas versiones cambian el objeto y por tanto no pue- 
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den tratar el objeto como un const. La version prefija devuelve el valor del objeto 
despues de cambiarlo, as! que usted espera recuperar el objeto que fue cambiado. De 
este modo, con la version prefija puede simplemente revolver *this como una refe¬ 
renda. Se supone que la version postfija devolvera el valor antes de que sea cambia¬ 
do, luego esta forzado a crear un objeto separado para representar el valor y devol- 
verlo. Asi que con la version postfija debe devolverlo por valor si quiere mantener el 
significado esperado. (Advierta que a veces encontrara operadores de incremento y 
decremento que devuelven un int o un bool para indicar, por ejemplo, que un objeto 
preparado para mo verse a traves de una lista esta al final de ella). Ahora la pregunta 
es: ^Deberia este devolverse como una referenda const o no const?. Si permite 
que el objeto sea modificado y alguien escribe (a++) . func (), func operara en 
la propia a, pero con (++a) . func (), funcopera en el objeto temporal devuelto 
por el operador postfijo operator++. Los objetos temporales son automaticamen- 
te const, asi que esto podria ser rechazado por el compilador, pero en favor de la 
consistencia tendria mas sentido hacerlos ambos const como hemos hecho aqui. O 
puede elegir hacer la version prefija no const y la postfija const. Debido a la varie- 
dad de significados que puede darle a los operadores de incremento y decremento, 
deben considerarse en terminos del caso individual. 

Retorno por valor como constante 

El retorno por valor como una constante puede parecer un poco sutil al principio, 
asi que es digno de un poco mas de explication. Considere el operador binario ope- 
rator+. Si lo ve en una expresion como f (a+b) , el resultado de a+b se convierte en 
un objeto temporal que se usara en la llamada a f (). Debido a que es temporal, es 
automaticamente const, asi que aunque, de forma explicita, haga el valor de retorno 
const o no, no tendra efecto. 

Sin embargo, tambien es posible mandar un mensaje al valor de retorno de a+b, 
mejor que simplemente pasarlo a la funcion. Por ejemplo, puede decir (a+b) . g ( ) 
en la que g () es algun metodo de Integer, en este caso. Haciendo el valor de re¬ 
torno const, esta indicando que solo un metodo const puede ser llamado sobre ese 
valor de retorno. Esto es correcto desde el punto de vista del const, porque le evita 
almacenar information potencialmente importante en un objeto que probablemente 
sera destruido. 

Optimization del retorno 

Advierta la manera que se usa cuando se crean nuevos objetos para ser devueltos 
por valor. En ope rat or +, por ejemplo: 

return Integer (left.i + right.i); 

Esto puede parecer en principio como una «funcion de llamada a un constructor 
pero no lo es. La sintaxis es la de un objeto temporal; la sentencia dice «crea un objeto 
Integer temporal y desvuelvelo». A causa de esto, puede pensar que el resultado 
es el mismo que crear un objeto local con nombre y devolverlo. Sin embargo, es algo 
diferente. Si en su lugar escribiera: 

Integer tmp(left.i + right.i); 

return tmp; 


sucederian tres cosas. La primera, se crea el objeto tmp incluyendo la llamada a 
su constructor. La segunda, el constructor de copia duplica tmp en la localization del 
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valor de retorno externo. La tercera, se llama al destructor para tmp cuando sale del 
ambito. 

En contraste, la aproximacion de «devolver un objeto temporal» funciona de ma- 
nera bastante diferente. Cuando el compilador ve eso, sabe que no tiene otra razon 
para crearlo mas que para devolverlo. El compilador aprovecha la ventaja que ofrece 
para construir el objeto directamente en la localization del valor de retorno externo a 
la funcion. Esto necesita de una sola y ordinaria llamada al constructor (la llamada al 
constructor de copia no es necesaria) y no hay llamadas al destructor porque nunca 
se crea un objeto local. De esta manera, no requiere nada mas que el conocimien- 
to del programador, y es significativamente mas eficiente. Esto a menudo se llama 
optimization del valor de retorno. 


12.3.4. Operadores poco usuales 

Varios operadores adicionales tienen una forma ligeramente diferente de ser so- 
brecargados. 

El subfndice, operator [ ] debe ser un metodo y precisa de un unico argumen- 
to. Dado que operator [ ] implica que el objeto que esta siendo utilizado como un 
array, a menudo devolvera una referenda de este operador, as! que puede ser con- 
venientemente usado en la parte derecha de un signo de igualdad. Este operador es 
muy comunmente sobrecargado; vera ejemplos en el resto del libro. 

Los operadores new y delete controlan la reserva dinamica de almacenamiento 
y se pueden sobrecargar de muchas maneras diferentes. Este tema se cub re en el 
capitulo 13. 

El operador coma 

El operador coma se llama cuando aparece despues de un objeto del tipo para el 
que esta definido. Sin embargo, «operator, » no se llama para listas de argumentos 
de funciones, solo para objetos fuera de ese lugar separados por comas. No parece 
haber un monton de usos practicos para este operador, solo es por consistencia del 
lenguaje. He aqui un ejemplo que muestra como la funcion coma se puede llamar 
cuando aparece antes de un objeto, as! como despues: 

//: C12:OverloadingOperatorComma.cpp 

#include <iostream> 

using namespace std; 

class After { 
public: 

const Afters operator,(const Afters) const { 
cout << "After::operator,()" << endl; 

return *this; 



class Before {} ; 

BeforeS operator,(int, BeforeS b) { 

cout << "Before::operator,()" << endl; 

return b; 

} 
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int main () { 

After a, b; 

a, b; // Operator comma called 
Before c; 

1, c; // Operator comma called 
} ///:- 


Las funciones globales permiten situar la coma antes del objeto en cuestion. El 
uso mostrado es bastante oscuro y cuestionable. Probablemente podria una lista se- 
parada por comas como parte de una expresion mas complicada, es demasiado refi- 
nado en la mayorla de las ocasiones. 

El operador -> 

El operador -> se usa generalmente cuando quiere hacer que un objeto parezca 
un puntero. Este tipo de objeto se suele llamar puntero inteligente o mas a menudo 
por su equivalente en ingles: smart pointer. Resultan especialmente utiles si quiere 
«envolver» una clase con un puntero para hacer que ese puntero sea seguro, o en 
la forma comun de un iterador, que es un objeto que se mueve a traves de una 
coleccion o contenedor de otros objetos y los selecciona de uno en uno cada 
vez, sin proporcionar acceso directo a la implementation del contenedor. (A menudo 
encontrara iteradores y contenedores en las librerias de clases, como en la Biblioteca 
Estandar de C++, descrita en el volumen 2 de este libro). 

El operador de indireccion de punteros (*) debe ser un metodo. Tiene otras restric- 
ciones atipicas: debe devolver un objeto (o una referencia a un objeto) que tambien 
tenga un operador de indireccion de punteros, o debe devolver un puntero que pue- 
da ser usado para encontrar a lo que apunta la flecha del operador de indirecion de 
punteros. He aqui un ejemplo simple: 

//: C12:SmartPointer.cpp 

#include <iostream> 

#include <vector> 

#include "../require.h" 
using namespace std; 

class Obj { 

static int i, j; 
public: 

void f() const { cout << i++ << endl; } 
void g() const { cout << j++ << endl; } 

} ; 


// Static member definitions: 

int Obj::i = 47; 
int Obj: : j = 11; 

// Container: 

class ObjContainer { 
vector<Obj*> a; 

public: 

void add(Obj* obj) { a.push_back(obj); } 

friend class SmartPointer; 

}; 
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class SmartPointer { 

ObjContainerS oc; 
int index; 

public: 

SmartPointer(ObjContainerS objc) : oc(objc) { 
index = 0; 

} 

// Return value indicates end of list: 
bool operator++() { // Prefix 

if (index >= oc.a.sizeO) return false; 
if (oc.a[++index] == 0) return false; 
return true; 

} 

bool operator++(int) { // Postfix 

return operator++ (); // Use prefix version 

} 

Obj* operator->() const { 

require(oc.a[index] != 0, "Zero value " 

"returned by SmartPointer::operator-> ()"); 
return oc.a[index]; 


} ; 


int main() { 

const int sz = 10; 

Obj o[sz]; 

ObjContainer oc; 
for(int i = 0; i < sz; i++) 
oc.add(&o[i]); // Fill it up 
SmartPointer sp(oc); // Create an iterator 
do { 

sp->f(); // Pointer dereference operator call 

sp->g(); 

} while (sp++); 

} ///:~ 


La clase Obj define los objetos que son manipulados en este programa. Las fun- 
ciones f () y g () simplemente escriben en pantalla los valores interesantes usan- 
do miembros de datos estaticos. Los punteros a estos objetos son almacenados en 
el interior de los contenedores del tipo ObjContainer usando su funcion add (). 
Ob jContanier parece un array de punteros, pero advertira que no hay forma de 
traer de nuevo los punteros. Sin embargo, SmartPointer se declara como una clase 
friend, asi que tiene permiso para mirar dentro del contenedor. La clase Smart- 
Pointer se parece mucho a un puntero inteligente - puede moverlo hacia adelante 
usando operator+t (tambien puede definir un operator —, no pasara del final 
del contenedor al que apunta, y genera (a traves del operador de indireccion de 
punteros) el valor al que apunta. Advierta que SmartPointer esta hecho a medida 
sobre el contenedor para el que se crea; a diferencia de un puntero normal, no hay 
punteros inteligentes de «proposito general». Aprendera mas sobre los punteros in- 
teligentes llamados «iteradores» en el ultimo capitulo de este libro y en el volumen 
2 (descargable desde FIXME:url www. BruceEckel. com). 

En main (), una vez que el contenedor oc se rellena con objetos Obj se crea un 
SmartPointer sp. La llamada al puntero inteligente sucede en las expresiones: 


sp—>f 0 ; 


// Llamada al puntero inteligente 
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sp->g (); 


Aqui, incluso aunque sp no tiene metodos f () y g (), el operador de indirec- 
cion de punteros automaticamente llama a esas funciones para Obj* que es devuelto 
por SmartPointer: :operator->. El compilador realiza todas las comprobacio- 
nes pertinentes para asegurar que la llamada a funcion funciona de forma correcta. 

Aunque la mecanica subyacente de los operadores de indireccion de punteros es 
mas compleja que la de los otros operadores, el objetivo es exactamente el mismo: 
proporcionar una sintaxis mas conveniente para los usuarios de sus clases. 

Un operador anidado 

Es mas comun ver un puntero inteligente o un clase iteradora anidada dentro de 
la clase a la que sirve. Se puede reescribir el ejemplo anterior para anidar SmartPo¬ 
inter dentro de Ob jContainer asi: 

//: C12:NestedSmartPointer.cpp 

#include <iostream> 

#include <vector> 

#include "../require.h" 
using namespace std; 

class Obj { 

static int i, j; 
public: 

void f() { cout << i++ << endl; } 
void g() { cout << j++ << endl; } 

} ; 

// Static member definitions: 

int Obj::i = 47; 
int Obj: : j = 11; 

// Container: 

class ObjContainer { 
vector<Obj*> a; 

public: 

void add(Obj* obj) { a.push_back(obj); } 

class SmartPointer; 
friend class SmartPointer; 
class SmartPointer { 

ObjContainerS oc; 
unsigned int index; 
public: 

SmartPointer(ObjContainerS objc) : oc(objc) { 
index = 0; 

} 

// Return value indicates end of list: 
bool operator++() { // Prefix 

if (index >= oc.a.sizeO) return false; 
if (oc.a[++index] == 0) return false; 
return true; 

} 

bool operator!!(int) { // Postfix 

return operator!! (); // Use prefix version 

} 
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Obj* operator-;() const { 

require(oc.a[index] != 0, "Zero value " 

"returned by SmartPointer::operator->()"); 
return oc.a[index]; 

} 

} ; 

// Function to produce a smart pointer that 
// points to the beginning of the ObjContainer: 
SmartPointer begin() | 

return SmartPointer (*this); 

} 


int main () { 

const int sz = 10; 

Obj o[sz]; 

ObjContainer oc; 
for(int i = 0; i < sz; i++) 
oc.add(&o[i]); // Fill it up 
ObjContainer::SmartPointer sp = oc.begin (); 
do { 

sp->f(); // Pointer dereference operator call 

sp->g(); 

} while (++sp); 

} ///:~ 


Ademas del anidamiento de la clase, hay solo dos diferencias aqui. La primera es 
la declaration de la clase para que pueda ser friend: 

class SmartPointer; 
friend SmartPointer; 

El compilador debe saber primero que la clase existe, antes de que se le diga que 
es «amiga». 

La segunda diferencia es en ObjContainer donde el metodo begin () produ¬ 
ce el SmartPointer que apunta al principio de la secuencia del ObjContainer. 
Aunque realmente es solo por conveniencia, es adecuado porque sigue la manera 
habitual de la librerla estandar de C++. 

Operador ->* 

El operador ->* es un operador binario que se comporta como todos los otros 
operadores binarios. Se proporciona para aquellas situaciones en las que quiera imi- 
tar el comportamiento producido por la sintaxis incorporada puntero a miembro, des- 
crita en el capitulo anterior. 

Igual que operator-;-, el operador de indirection de puntero a miembro se usa 
normalmente con alguna clase de objetos que representan un «puntero inteligente», 
aunque el ejemplo mostrado aqul sera mas simple para que sea comprensible. El 
truco cuando se define operator-;* es que debe devolver un objeto para el que 
operator () pueda ser llama do con los argumentos para la funcion miembro que 
usted llama. 

La llamada a funcion operator () debe ser un metodo, y es unico en que per- 
mite cualquier numero de argumentos. Hace que el objeto parezca realmente una 
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funcion. Aunque podria definir varias funciones sobrecargadas operator () con 
diferentes argumentos, a menudo se usa para tipos que solo tienen una operacion 
simple, o al menos una especialmente destacada. En el Volumen2 vera que la Libreria 
Estandar de C++ usa el operador de llamada a funcion para crear «objetos-funcion». 

Para crear un operator->* debe primero crear una clase con un operator (- 
) que sea el tipo de objeto que operator->* devolvera. Esta clase debe, de algun 
modo, capturar la informacionnecesariapara que cuando operator () sea llamada 
(lo que sucede automaticamente), el puntero a miembro sea indireccionado para el 
objeto. En el siguiente ejemplo, el constructor de FunctionOb ject captura y alma- 
cena el puntero al objeto y el puntero a la funcion miembro, y entonces operator () 
los usa para hacer la verdadera llamada puntero a miembro: 

//: C12:PointerToMemberOperator.cpp 

#include <iostream> 

using namespace std; 

class Dog { 
public: 

int run(int i) const { 

cout << "run\n"; 

return i; 

} 

int eat (int i) const { 

cout << "eat\n"; 

return i; 

} 

int sleep (int i) const { 

cout « "ZZZ\n"; 

return i; 

} 

typedef int (Dog::*PMF) (int) const; 

// operator->* must return an object 
// that has an operator () : 
class FunctionObject { 

Dog* ptr; 

PMF pmera; 
public: 

// Save the object pointer and member pointer 
FunctionObject (Dog* wp, PMF pmf) 

: ptr(wp), pmem(pmf) { 

cout << "FunctionObject constructor\n"; 

} 

// Make the call using the object pointer 
// and member pointer 

int operator () (int i) const { 

cout << "FunctionObject::operator()\n"; 
return (ptr->*pmem)(i); // Make the call 


FunctionObject operator->*(PMF pmf) { 
cout << "operator->*" << endl; 
return FunctionObject(this, pmf) ; 


} ; 


int main () { 

Dog w; 
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Dog::PMF pmf = &Dog::run; 
cout << (w->*pmf)(1) << endl; 
pmf = &Dog::sleep; 
cout << (w->*pmf)(2) << endl; 
pmf = &Dog: :eat; 
cout << (w->*pmf)(3) << endl; 
} ///:~ 


Dog tiene tres metodos, todos toman un argumento entero y devuelven un entero. 
PMC es un typedef para simplificar la definicion de un puntero a miembro para los 
metodos de Dog. 

Una FunctionObject es creada y devuelta por operator-;-*. Dese cuenta 
que operator-;* conoce el objeto para el que puntero a miembro esta siendo 11a- 
mado (this) y el puntero a miembro, y los pasa al constructor FunctionOb ject 
que almacena sus valores. Cuando se llama a operator-;*, el compilador inme- 
diatamente lo revuelve y llama a operator () para el valor de retorno de oper¬ 
ator-;*, pasandole los argumentos que le fueron pasados a operator-;*. Fu¬ 
nctionOb ject : : operator () toma los argumentos e desreferencia el puntero a 
miembro «real» usando los punteros a objeto y a miembro almacenados. 

Percatese de que lo que esta ocurriendo aqui, justo como con operator-;, se 
inserta en la mitad de la llamada a operator-;*. Esto permite realizar algunas 
operaciones adicionales si se necesita. 

El mecanismo operator-;* implementado aqui solo trabaja para funciones 
miembro que toman un argumento entero y devuelven otro entero. Esto es una li- 
mitacion, pero si intenta crear mecanismos sobrecargados para cada posibilidad di- 
ferente, vera que es una tarea prohibitiva. Afortunadamente, el mecanismo de plan- 
tillas de C++ (descrito el el ultimo capitulo de este libro, y en el volumen2) esta 
disenado para manejar semejante problema. 


12.3.5. Operadores que no puede sobrecargar 

Hay cierta clase de operadores en el conjunto disponible que no pueden ser sobre¬ 
cargados. La razon general para esta restriccion es la seguridad. Si estos operadores 
fuesen sobrecargables, podria de algun modo arriesgar o romper los mecanismos de 
seguridad, hacer las cosas mas dificiles o confundir las costumbres existentes. 

1. El operador de seleccion de miembros operator .. Actualmente, el punto tie¬ 
ne significado para cualquier miembro de una clase, pero si se pudiera sobre¬ 
cargar, no se podria acceder a miembros de la forma normal; en lugar de eso 
deberia usar un puntero y la flecha operator-;. 

2. La indirection de punteros a miembros operator . * por la misma razon que 

operator.. 

3. No hay un operador de potencia. La election mas popular para este era oper¬ 
ator** de Fortram, pero provoca casos de analisis gramatical dificiles. C tam- 
poco tiene un operador de potencia, asi que C++ no parece tener necesidad de 
uno porque siempre puede realizar una llamada a una funcion. Un operador de 
potencia anadira una notation adecuada, pero ninguna nueva funcionalidad a 
cuenta de una mayor complejidad del compilador. 

4. No hay operadores definidos por el usuario. Esto es, no puede crear nuevos 
operadores que no existan ya. Una parte del problema es como determinar la 
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precedencia, y otra parte es la falta de necesidad a costa del problema inheren- 
te. 

5. No puede cambiar las reglas de precedencia. Son lo suficientemente diflciles 
de recordar como son sin dejar a la gente jugar con ellas. 

12.4. Operadores no miembros 

En algunos de los ejemplos anteriores, los operadores pueden ser miembros o no, 
y no parece haber mucha diferencia. Esto normalmente provoca la pregunta, «,;Cual 
deberla elegir?». En general, si no hay ninguna diferencia deberlan ser miembros, 
para enfatizar la asociacion entre el operador y su clase. Cuando el operando de la 
izquierda es siempre un objeto de la clase actual funciona bien. 

Sin embargo, a veces querra que el operando de la izquierda sea un objeto de 
alguna otra clase. Un caso tlpico en el que ocurre eso es cuando se sobrecargan los 
operadores << y >> para los flujos de entrada/salida. Dado que estos flujos son una 
librerla fundamental en C++, probablemente querra sobrecargar estos operadores 
para la mayorla de sus clases, por eso el proceso es digno de tratarse: 

// : C12 :IostreamOperatorOverloading.cpp 
// Example of non-member overloaded operators 

#include "../require.h" 

#include <iostream> 

#include <sstream> // "String streams" 

#include <cstring> 
using namespace std; 

class IntArray { 
enum { s z = 5 }; 
int i[sz]; 

public: 

IntArray() { memset(i, 0, sz* sizeof(*i)); } 

int& operator [] (int x) { 

require(x >= 0 && x < sz, 

"IntArray::operator[] out of range"); 

return i[x]; 

} 

friend ostreamS 

operator« (ostreamS os, const IntArrayS ia) ; 
friend istreams 

operator» (istreamS is, IntArrayS ia); 

} ; 


ostreamS 

operator« (ostreamS os, const IntArrayS ia) { 
for(int j = 0; j < ia.sz; j++) { 

os << ia.i [ j]; 
if (j != ia.sz -1) 
os << ", 

} 

os << endl; 

return os; 


istreams operator>> (istreams is, IntArrayS ia){ 
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for(int j = 0; j < ia.sz; j++) 
is >> ia.i[j]; 

return is; 


int main() { 

stringstream input ("47 34 56 92 103"); 
IntArray I; 
input >> I; 

I[4] = -1; // Use overloaded operator [] 
cout << I; 

} ///:- 


Esta clase contiene tambien un operador sobrecargado operator [ ] el cual de- 
vuelve una referenda a un valor legitimo en el array. Dado que devuelve una refe¬ 
renda, la expresion: 

I[4] = -1; 


No solo parece mucho mas adecuada que si se usaran punteros, tambien causa el 
efecto deseado. 

Es importante que los operadores de desplazamiento sobrecargados se pasen y 
devuelvan por referenda, para que los cambios afecten a los objetos externos. En las 
definiciones de las funciones, expresiones como: 

os << ia.i[j]; 


provocan que sean llamadas las funciones de los operadores sobrecargados (esto 
es, aquellas definidas en iostream). En este caso, la funcion llamada es ostreamS 
operator<< (ostreamS, int) dado que ia [i] . j se resuelve a int. 

Una vez que las operaciones se han realizado en istream o en ostream se de¬ 
vuelve para que se pueda usaren expresiones mas complicadas. 

En main () se usa un nuevo tipo de iostream: el stringstream (declarado en 
<sstream>). Es una clase que toma una cadena (que se puede crear de un array de 
char, como se ve aqui) y lo convierte en un iostream. En el ejemplo de arriba, esto 
significa que los operadores de desplazamiento pueden ser comprobados sin abrir 
un archivo o sin escribir datos en la ltnea de comandos. 

La manera mostrada en este ejemplo para el extractor y el insertador es estandar. 
Si quiere crear estos operadores para su propia clase, copie el prototipo de la funcion 
y los tipos de retorno de arriba y siga el estilo del cuerpo. 


12.4.1. Directrices basicas 

Murray 1 sugiere estas reglas de estilo para elegir entre miembros y no miembros: 


1 Rob Murray, C++ Strategies & Tactics , Addison Wesley, 1993, pagina 47. 
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Operador 

Uso recomendado 

Todos los operadores unarios 

miembro 

- 0 [] -> ->* 

debe ser miembro 

+=-=/= *= ~= &= 1 =%= »= «= 

miembro 

El resto de operadores binarios 

no miembro 


Cuadro 12.1: Directrices para elegir entre miembro y no-miembro 


12.5. Sobrecargar la asignacion 

Una causa comun de confusion para los nuevos programadores de C++ es la 
asignacion. De esto no hay duda porque el signo = es una operacion fundamental 
en la programacion, directamente hasta copiar un registro en el nivel de maquina. 
Ademas, el constructor de copia (descrito en el capltulo 11) [FIXME:referencia] es 
invocado cuando el signo = se usa asl: 

MyType b; 

MyType a = b; 

a = b; 

En la segunda lfnea, se define el objeto a. Se crea un nuevo objeto donde no existia 
ninguno. Dado que ya sabe hasta que punto es quisquilloso el compilador de C++ 
respecto a la inicializacion de objetos, sabra que cuando se define un objeto, siempre 
se invoca un constructor. Pero que constructor?, a se crea desde un objeto existente 
MyType (b, en el lado derecho del signo de igualdad), asi que solo hay una opcion: el 
constructor de copia. Incluso aunque el signo de igualdad este involucrado, se llama 
al constructor de copia. 

En la tercera linea, las cosas son diferentes. En la parte izquierda del signo igual, 
hay un objeto previamente inicializado. Claramente, no se invoca un constructor pa¬ 
ra un objeto que ya ha sido creado. En este caso MyType: : operator= se llama 
para a, tomando como argumento lo que sea que aparezca en la parte derecha. (Pue- 
de tener varias funciones operator= que tomen diferentes argumentos en la parte 
derecha). 

Este comportamiento no esta restringido al constructor de copia. Cada vez que 
inicializa un objeto usando un signo = en lugar de la forma usual de llamada al 
constructor, el compilador buscara un constructor que acepte lo que sea que haya en 
la parte derecha: 

//: C12:CopyingVsInitialization.cpp 

class Fi { 
public: 

Fi () {} 

} ; 


class Fee { 
public: 

Fee (int) {} 

Fee (const Fi&) { } 


int main() { 

Fee fee = 1; // Fee (int) 
Fi fi; 
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Fee fum = fi; // Fee(Fi) 
} /// : ~ 


Cuando se trata con el signo =, es importante mantener la diferencia en mente: 
Si el objeto no ha sido creado todavla, se requiere una inicializacion; en otro caso se 
usa el operador de asignacion =. 

Es incluso mejor evitar escribir codigo que usa = para la inicializacion; en cambio, 
use siempre la manera del constructor explicito. Las dos construcciones con el signo 
igual se convierten en: 

Fee fee (1); 

Fee fum(fi); 

De esta manera, evitara confundir a sus lectores. 


12.5.1. Comportamiento del operador = 

En Integer. h y en Byte . h vimos que el operador = solo puede ser una funcion 
miembro. Esta intimamente ligado al objeto que hay en la parte izquierda del =. Si 
fuese posible definir operator= de forma global, entonces podria intentar redefinir 
el signo = del lenguaje: 

int operator= (int, MyType); // Global = !No permitido! 


El compilador evita esta situacion obligandole a hacer un metodo operators 

Cuando cree un operators debe copiar toda la informacion necesaria desde el 
objeto de la parte derecha al objeto actual (es decir, el objeto para el que operato- 
r= esta siendo llamado) para realizar lo que sea que considere «asignacion» para su 
clase. Para objetos simples, esto es trivial: 

//: Cl2:SimpleAssignment.cpp 
// Simple operator=() 

#include <iostream> 

using namespace std; 

class Value { 

int a, b; 

float c; 
public: 

Value (int aa = 0, int bb = 0, float cc = 0.0) 

: a(aa), b(bb), c(cc) {} 

Values operator=(const Values rv) { 
a = rv.a; 
b = rv.b; 
c = rv.c; 
return *this; 

} 

friend ostreams 

operator« (ostreamS os, const Values rv) { 
return os << "a = " << rv.a << ", b = " 

<< rv.b << ", c = " << rv.c; 

} 
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int main () { 

Value a, b(1, 2, 
cout << "a: " << 
cout << "b: " << 
a = b; 

cout << "a after 
} /// :~ 


3.3) ; 

a << endl; 
b << endl; 

assignment: 


<< a << endl; 


Aqui, el objeto de la parte izquierda del igual copia todos los elementos del objeto 
de la parte derecha, y entonces devuelve una referenda a si mismo, lo que permite 
crear expresiones mas complejas. 

Este ejemplo incluye un error comon. Cuando asignane dos objetos del mismo 
tipo, siempre deberla comprobar primero la auto-asignacion: ^Esta asignado el ob¬ 
jeto a si mismo?. En algunos casos como este, es inofensivo si realiza la operation 
de asignacion en todo caso, pero si se realizan cambios a la implementation de la 
clase, puede ser importante y si no lo toma con una cuestion de costumbre, puede 
olvidarlo y provocar errores diflciles de encontrar. 

Punteros en clases 

/Que ocurre si el objeto no es tan simple?. Por ejemplo, /que pasa si el objeto 
contiene punteros a otros objetos?. Solo copiar el puntero significa que obtendra dos 
objetos que apuntan a la misma localization de memoria. En situaciones como esta, 
necesita hacer algo de contabilidad. 

Hay dos aproximaciones a este problema. La tecnica mas simple es copiar lo que 
quiera que apunta el puntero cuando realiza una asignacion o una construction de 
copia. Esto es sencillo: 

//: C12:CopyingWithPointers.cpp 
// Solving the pointer aliasing problem by 
// duplicating what is pointed to during 
// assignment and copy-construction. 

#include ".. /require.h" 

#include <string> 

#include <iostream> 

using namespace std; 

class Dog { 

string nm; 

public: 

Dog (const strings name) : nm(name) { 

cout << "Creating Dog: " << *this << endl; 

} 

// Synthesized copy-constructor S operator= 

// are correct. 

// Create a Dog from a Dog pointer: 

Dog (const Dog* dp, const strings msg) 

: nm(dp->nm + msg) { 

cout << "Copied dog " << *this << " from " 

<< *dp << endl; 

} 


~Dog () { 
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cout << "Deleting Dog: " << *this << endl; 

} 

void rename (const strings newName) { 
nm = newName; 

cout << "Dog renamed to: " << *this << endl; 

} 

friend ostreamS 

operator« (ostreamS os, const Dog& d) { 

return os << "[" << d.nm << "]"; 



class DogHouse { 

Dog* p; 

string houseName; 

public: 

DogHouse(Dog* dog, const strings house) 

: p(dog), houseName(house) {} 

DogHouse (const DogHouseS dh) 

: p (new Dog(dh.p, " copy-constructed")), 
houseName(dh.houseName 

+ " copy-constructed") {} 

DogHouseS operator=(const DogHouseS dh) { 

// Check for self-assignment: 
if (Sdh != this) { 

p = new Dog(dh.p, " assigned"); 
houseName = dh.houseName + " assigned"; 

} 

return *this; 

} 

void renameHouse (const strings newName) { 
houseName = newName; 

} 

Dog* getDogO const { return p; } 

-DogHouse () { delete p; } 

friend ostreamS 

operator« (ostreamS os, const DogHouseS dh) { 
return os << "[" << dh.houseName 
<< "] contains " << *dh.p; 



int main () { 

DogHouse fidos (new Dog("Fido"), "FidoHouse") ; 
cout << fidos << endl; 

DogHouse fidos2 = fidos; // Copy construction 

cout << fidos2 << endl; 

fidos2.getDog()->rename("Spot"); 

fidos2.renameHouse("SpotHouse") ; 

cout << fidos2 << endl; 

fidos = fidos2; // Assignment 

cout << fidos << endl; 

fidos.getDog()->rename("Max"); 

fidos2.renameHouse("MaxHouse"); 

} ///:- 


Dog es una clase simple que contiene solo una cadena con el nombre del perro. 
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Sin embargo, generalmente sabra cuando le sucede algo al perro porque los construc- 
tores y destructores imprimen informacion cuando se invocan. Frjese que el segundo 
constructor es un poco como un constructor de copia excepto que toma un puntero 
a Dog en vez de una referenda, y tiene un segundo argumento que es un mensaje a 
ser concatenado con el nombre del perro. Esto se hace as! para ayudar a rastrear el 
comportamiento del programa. 

Puede ver que cuando un metodo imprime informacion, no accede a esa informa¬ 
cion directamente sino que manda *this a cout. Este a su vez llama a ostream 
operator«. Es aconsejable hacer esto as! dado que si quiere reformatear la mane- 
ra en la que informacion del perro es mostrada (como hice anadiendo el «[» y el «]») 
solo necesita hacerlo en un lugar. 

Una DogHouse contiene un Dog* y demuestra las cuatro funciones que siempre 
necesitara definir cuando sus clases contengan punteros: todos los constructores ne- 
cesarios usuales, el constructor de copia, ope rat or = (se define o se deshabilita) y 
un destructor. Operator= comprueba la auto-asignacion como una cuestion de es- 
tilo, incluso aunque no es estrictamente necesario aqul. Esto virtualmente elimina la 
posibilidad de que olvide comprobar la auto-asignacion si cambia el codigo. 

Contabilidad de referencias 

En el ejemplo de arriba, el constructor de copia y el operador = realizan una co¬ 
pia de lo que apunta el puntero, y el destructor lo borra. Sin embargo, si su objeto 
requiere una gran cantidad de memoria o una gran initialization fija, a lo mejor 
puede querer evitar esta copia. Una aproximacion comun a este problema se llama 
conteo de referencias. Se le da inteligencia al objeto que esta siendo apuntado de tal for¬ 
ma que sabe cuantos objetos le estan apuntado. Entonces la construction por copia 
o la asignacion consiste en anadir otro puntero a un objeto existente e incrementar la 
cuenta de referencias. La destruction consiste en reducir esta cuenta de referencias y 
destruir el objeto si la cuenta llega a cero. 

<ti’ero que pasa si quiere escribir el objeto(Dog en el ejemplo anterior)?. Mas de 
un objeto puede estar usando este Dog luego podria estar modificando el perro de 
alguien mas a la vez que el suyo, lo cual no parece ser muy amigable. Para resol¬ 
ver este problema de «solapamiento» se usa una tecnica adicional llamada copia-en- 
escritura. Antes de escribir un bloque de memoria, debe asegurarse que nadie mas 
lo esta usando. Si la cuenta de referencia es superior a uno, debe realizar una copia 
personal del bloque antes de escribirlo, de tal manera que no moleste el espacio de 
otro. He aqui un ejemplo simple de conteo de referencias y copia-en-escritura: 

//: C12:Referencecounting.cpp 
// Reference count, copy-on-write 

#include /require.h" 

#include <string> 

#include <iostream> 

using namespace std; 

class Dog { 

string nm; 

int refcount; 

Dog (const strings name) 

: nm(name), refcount(l) { 

cout << "Creating Dog: " << *this << endl; 

} 

// Prevent assignment: 

Dog& operator=(const Dog& rv); 
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public: 

// Dogs can only be created on the heap: 
static Dog* make(const strings name) { 
return new Dog (name); 

} 

Dog(const Dogs d) 

: nm(d.nm + " copy"), refcount(l) { 
cout << "Dog copy-constructor: " 

<< *this << endl; 

} 

~Dog () { 

cout << "Deleting Dog: " << *this << endl; 

} 

void attach() { 

++refcount; 

cout << "Attached Dog: " << *this << endl; 

} 

void detach() { 

require(refcount != 0); 

cout << "Detaching Dog: " << *this << endl; 
// Destroy object if no one is using it: 

if(—refcount == 0) delete this; 

} 

// Conditionally copy this Dog. 

// Call before modifying the Dog, assign 
// resulting pointer to your Dog*. 

Dog* unalias () { 

cout << "Unaliasing Dog: " << *this << endl; 
// Don't duplicate if not aliased: 

if(refcount == 1) return this; 

—refcount; 

// Use copy-constructor to duplicate: 

return new Dog(*this); 

} 

void rename(const strings newName) 1 
nm = newName; 

cout << "Dog renamed to: " << *this << endl; 

} 

friend ostreams 

operator«(ostreamS os, const Dogs d) { 
return os << "[" << d.nm << "], rc = " 

<< d.refcount; 

} 

) ; 


class DogHouse { 

Dog* p; 

string houseName; 

public: 

DogHouse(Dog* dog, const strings house) 

: p(dog), houseName(house) { 
cout << "Created DogHouse: "<< *this << endl; 

} 

DogHouse (const DogHouseS dh) 

: p(dh.p), 

houseName("copy-constructed " + 
dh.houseName) { 
p->attach (); 
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cout << "DogHouse copy-constructor: " 

<< *this << endl; 

} 

DogHouseS operator=(const DogHouseS dh) { 

// Check for self-assignment: 
if (&dh != this) { 

houseName = dh.houseName + " assigned"; 

// Clean up what you're using first: 
p->detach(); 

p = dh.p; // Like copy-constructor 

p->attach(); 

} 

cout << "DogHouse operator= : " 

<< *this << endl; 
return *this; 

} 

// Decrement refcount, conditionally destroy 
-DogHouse() { 

cout << "DogHouse destructor: " 

<< *this << endl; 
p->detach(); 

} 

void renameHouse (const strings newName) { 
houseName = newName; 

} 

void unalias () { p = p->unalias (); } 

// Copy-on-write. Anytime you modify the 
// contents of the pointer you must 
// first unalias it: 

void renameDog (const strings newName) { 
unalias () ; 
p->rename(newName); 

} 

// ... or when you allow someone else access: 
Dog* getDog () { 

unalias () ; 

return p; 

} 

friend ostreams 

operator« (ostreamS os, const DogHouseS dh) { 
return os << "[" << dh.houseName 
<< "] contains " << *dh.p; 


} ; 


int main() { 

DogHouse 

fidos(Dog::make("Fido"), "FidoHouse"), 
spots(Dog::make("Spot"), "SpotHouse"); 
cout << "Entering copy-construction" << endl; 
DogHouse bobs(fidos); 

cout << "After copy-constructing bobs" << endl; 

cout << "fidos:" << fidos << endl; 

cout << "spots:" << spots << endl; 

cout << "bobs:" << bobs << endl; 

cout << "Entering spots = fidos" << endl; 

spots = fidos; 

cout << "After spots = fidos" << endl; 
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cout << "spots:" << spots << endl; 

cout << "Entering self-assignment" << endl; 

bobs = bobs; 

cout << "After self-assignment" << endl; 
cout << "bobs:" << bobs << endl; 

// Comment out the following lines: 

cout << "Entering rename(\"Bob\")" << endl; 

bobs.getDog()->rename("Bob"); 

cout << "After rename(\"Bob\")" << endl; 

} //f§~ 


La clase Dog es el objeto apuntado por DogHouse. Contiene una cuenta de refe- 
rencias y metodos para controlar y leer la cuenta de referencias. Hay un constructor 
de copia de modo que puede crear un nuevo Dog a partir de uno existente. 

La funcion attach () incrementa la cuenta de referencias de un Dog para indicar 
que hay otro objeto usandolo. La funcion detach () decrementa la cuenta de refe¬ 
rencias. Si llega a cero, entonces nadie mas lo esta usando, asi que el metodo destruye 
su propio objeto llamando a delete this. 

Antes de que haga cualquier modificacion (como renombrar un Dog), deberia 
asegurarse de que no esta cambiando un Dog que algun otro objeto esta usando. 
Hagalo llamando a DogHouse : : unalias () , que llama a Dog : : unalias (). Esta 
ultima funcion devolvera el puntero a Dog existente si la cuenta de referencias es 
uno (lo que significa que nadie mas esta usando ese Dog), pero duplicara Dog si esa 
cuenta es mayor que uno. 

El constructor de copia, ademas de pedir su propia memoria, asigna Dog al Dog 
del objeto fuente. Entonces, dado que ahora hay un objeto mas usando ese bloque de 
memoria, incrementa la cuenta de referencias llamando a Dog: : attach (). 

El operador = trata con un objeto que ha sido creado en la parte izquierda del =, 
asi que primero debe limpiarlo llamando a detach () para ese Dog, lo que destruira 
el Dog viejo si nadie mas lo esta usando. Entonces operator= repite el comporta- 
miento del constructor de copia. Advierta que primero realiza comprobaciones para 
detectar cuando esta asignando el objeto a si mismo. 

El destructor llama a detach () para destruir condicionalmente el Dog. 

Para implementar la copia-en-escritura, debe controlar todas las operaciones que 
escriben en su bloque de memoria. Por ejemplo, el metodo renameDog () le permite 
cambiar valores en el bloque de memoria. Pero primero, llama a unalias () para 
evitar la modificacion de un Dog solapado (un Dog con mas de un objeto DogHou¬ 
se apuntandole). Y si necesita crear un puntero a un Dog desde un DogHouse debe 
llamar primero a unalias () para ese puntero. 

La funcion main () comprueba varias funciones que deben funcionar correcta- 
mente para implementar la cuenta de referencias: el constructor, el constructor de 
copia, operator = y el destructor. Tambien comprueba la copia-en-escritura llaman¬ 
do a renameDog(). 

He aqui la salida (despues de un poco de reformateo): 

Creando Dog: [Fido], rc = 1 
CreadoDogHouse: [FidoHouse] 
contiene [Fido], rc = 1 
Creando Dog: [Spot], rc = 1 
CreadoDogHouse: [SpotHouse] 
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contiene [Spot], rc = 1 
Entrando en el constructor de copia 
Dog naadido:[Fido], rc = 2 
DogHouse constructor de copia 
[construido por copia FidoHouse] 
contiene [Fido], rc = 2 

Despues de la oconstruccin por copia de Bobs 

fidos:[FidoHouse] contiene [Fido], rc = 2 

spots:[SpotHouse] contiene [Spot], rc = 1 

bobs:[construido por copia FidoHouse] 

contiene[Fido], rc = 2 

Entrando spots = fidos 

Eliminando perro: [Spot], rc = 1 

Borrando Perro: [Spot], rc = On 

Aadido Dog: [Fido], rc = 3 

DogHouse operador= : [FidoHouse asignado] 

contiene[Fido], rc = 3 

Despues de spots = fidos 

spots:[FidoHouse asignado] contiene [Fido], rc = 3 
Entrando en la auto oasignacin 

DogHouse operador= : [construido por copia FidoHouse] 

contiene [Fido], rc = 3 

Despues de la auto oasignacin 

bobs:[construido por copia FidoHouse] 

contiene [Fido], rc = 3 

Entando rename("Bob") 

Despues de rename("Bob") 

DogHouse destructor: [construido por copia FidoHouse] 

contiene [Fido], rc = 3 

Eliminando perro: [Fido], rc = 3 

DogHouse destructor: [FidoHouse asignado] 

contiene [Fido], rc = 2 

Eliminando perro: [Fido], rc = 2 

DogHouse destructor: [FidoHouse] 

contiene [Fido], rc = 1 

Eliminando perro: [Fido], rc = 1 

Borrando perro: [Fido], rc = 0 

Estudiando la salida, rastreando el codigo fuente y experimentando con el pro- 
grama, podra ahondar en la comprension de estas tecnicas. 

Creacion automatica del operador = 

Dado que asignar un objeto a otro del mismo tipo es una operacion que la mayorla 
de la gente espera que sea posible, el compilador automaticamente creara un typ- 
e : : operator= (type ) si usted el programador no proporciona uno. El comporta- 
miento de este operador imita el del constructor de copia creado automaticamente; 
si la clase contiene objetos (o se deriva de otra clase), se llama recursivamente a o- 
perator= para esos objetos. A esto se le llama asignacion miembro a miembro. Por 
ejemplo: 

//: C12:AutomaticOperatorEquals.cpp 

#include <iostream> 

using namespace std; 

class Cargo { 
public: 
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Cargos operator=(const Cargos) { 

cout << "inside Cargo::operator= ()" << endl; 

return *this; 



class Truck { 
Cargo b; 

} ; 


int main () { 

Truck a, b; 

a = b; // Prints: "inside Cargo::operator= () " 
} ///:~ 


El operador= generado automaticamente para Truck llama a Cargo: : oper¬ 
ators 

En general, no querra que el compilador haga esto por usted. Con clases de cual- 
quier sofisticacion (jEspecialmente si contienen punteros!) querra crear de forma ex- 
plicita un operators Si realmente no quiere que la gente realice asignaciones, de¬ 
clare operator= como una metodo privado. (No necesita definirla a menos que la 
este usando dentro de la clase). 


12.6. Conversion automatica de tipos 

En C y C++, si el compilador encuentra una expresion o una llamada a funcion 
que usa un tipo que no es el que se requiere, a menudo podra realizar una conversion 
automatica de tipos desde el tipo que tiene al tipo que necesita. En C++, puede con- 
seguir este mismo efecto para los tipos definidos por el usuario creando funciones 
de conversion automatica de tipos. Estas funciones se pueden ver en dos versiones: 
un tipo particular de constructores y un operador sobrecargado. 


12.6.1. Conversion por constructor 

Si define un constructor que toma como su unico argumento un objeto (o refe¬ 
renda) de otro tipo, ese constructor permite al compilador realizar una conversion 
automatica de tipos. Por ejemplo: 

//: Cl2:AutomaticTypeConversion.cpp 
// Type conversion constructor 

class One { 
public: 

One () {} 

} ; 


class Two { 
public: 

Two (const Ones) {} 

} ; 


void f(Two) {} 
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int main () { 

One one; 

f(one); // Wants a Two, has a One 
} ///:- 


Cuando el compilador ve que f () es invocada pasando un objeto One, mira en la 
declaration de f () y ve que requiere un Two. Entonces busca si hay alguna manera 
de conseguir un Two a partir de un One, encuentra el constructor Two : : Two (One) 
y lo llama. Pasa el objeto Two resultante a f (). 

En este caso, la conversion automatica de tipos le ha salvado del problema de 
definir dos versiones sobrecargadas de f (). Sin embargo el coste es la llamada oculta 
al constructor de Two, que puede ser importante si esta preocupado por la eficiencia 
de las llamadas a f () , 

Evitar la conversion por constructor 

Hay veces en que la conversion automatica de tipos via constructor puede oca- 
sionar problemas. Para desactivarlo, modifique el constructor anteponiendole la pa- 
labra reservada explicit (que solo funciona con constructores). Asi se ha hecho 
para modificar el constructor de la clase Two en el ejemplo anterior: 

//: C12:ExplicitKeyword.cpp 
// Using the "explicit" keyword 

class One { 
public: 

One () {} 

} ; 


class Two { 
public: 

explicit Two (const Ones) {} 

} ; 


void f(Two) {} 

int main() { 

One one; 

//! f (one); //No auto conversion allowed 

f(Two(one)); // OK — user performs conversion 
} ///:~ 


Haciendo el constructor de Two explicito, se le dice al compilador que no realice 
ninguna conversion automatica de tipos usando ese constructor en particular (si se 
podrian usar otros constructores no explicitos de esa clase para realizar conversiones 
automaticas). Si el usuario quiere que ocurra esa conversion, debe escribir el codigo 
necesario. En el codigo de arriba, f (Two (one) ) crea un objeto temporal de tipo T- 
wo a partir de one, justo como el compilador hizo automaticamente en la version 
anterior. 
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12.6.2. Conversion por operador 

La segunda forma de producir conversiones automaticas de tipo es a traves de 
la sobrecarga de operadores. Puede crear un metodo que tome el tipo actual y lo 
convierta al tipo deseado usando la palabra reservada operator seguida del tipo al 
que quiere convertir. Esta forma de sobrecarga de operadores es unica porque parece 
que no se especifica un tipo de retorno — el tipo de retorno es el nombre del operador 
que esta sobrecargando. He aqui un ejemplo: 

//: C12:OperatorOverloadingConversion.cpp 

class Three { 
int i; 
public: 

Three (int ii = 0, int = 0) : i(ii) {} 

1 ; 


class Four { 
int x; 
public: 

Four (int xx) : x (xx) {} 

operator Three () const { return Three(x); } 

1 ; 


void g (Three) {} 

int main() { 

Four four(1); 
g(four); 

g(l); // Calls Three(l,0) 

} ///:~ 


Con la tecnica del constructor, la clase destino realiza la conversion, pero con 
los operadores, la realiza la clase origen. El valor de la tecnica del constructor es que 
puede anadir una nueva ruta de conversion a un sistema existente al crear una nueva 
clase. Sin embargo, creando un constructor con un unico argumento siempre define 
una conversion automatica de tipos (incluso si requiere mas de un argumento si el 
resto de los argumentos tiene un valor por defecto), que puede no ser lo que desea 
(en cuyo caso puede desactivarlo usando explicit). Ademas, no hay ninguna for¬ 
ma de usar una conversion por constructor desde un tipo definido por el usuario a 
un tipo incorporado; eso solo es posible con la sobrecarga de operadores. 

Reflexividad 

Una de las razones mas convenientes para usar operadores sobrecargados glo- 
bales en lugar de operadores miembros es que en la version global, la conversion 
automatica de tipos puede aplicarse a cualquiera de los operandos, mientras que 
con objetos miembro, el operando de la parte izquierda debe ser del tipo apropiado. 
Si quiere que ambos operandos sean convertidos, la version global puede ahorrar un 
monton de codigo. He aqui un pequeno ejemplo: 

//: C12:ReflexivitylnOverloading.cpp 

class Number { 
int i; 
public: 
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Number (int ii = 0) : i(ii) {} 

const Number 

operator!(const Numbers n) const { 
return Number(i + n.i); 

} 

friend const Number 

operator-(const Numbers, const Numbers); 

} ; 

const Number 

operator-(const Numbers nl, 

const Numbers n2) { 

return Number (nl.i - r.2 .: ) ; 

} 

int main () { 

Number a(47), b(ll); 

a + b; //OK 

a + 1; // 2nd arg converted to Number 
//! 1 + a; // Wrong! 1st arg not of type Number 
a - b; //OK 

a - 1; // 2nd arg converted to Number 
1 - a; // 1st arg converted to Number 
} ///:- 


La clase Number tiene tanto un miembro operator! como un friend oper¬ 
ator-. Dado que hay un constructor que acepta un argumento int simple, se puede 
convertir un int automaticamente a Number, pero solo bajo las condiciones adecua- 
das. En main (), puede ver que sumar un Number a otro Number funciona bien 
dado que tiene una correspondencia exacta con el operador sobrecargado. Ademas, 
cuando el compilador ve un Number seguido de un + y de un int, puede hacer la 
correspondencia al metodo Number : : operator! y convertir el argumento int an 
Number usando el constructor. Pero cuando ve un int, un ! y un Number, no sabe 
que hacer porque todo lo que tiene es Number: : operator! que requiere que el 
operando de la izquierda sea ya un objeto Number. Asi que, el compilador genera 
un error. 

Con friend operator- las cosas son diferentes. El compilador necesita relle- 
nar ambos argumentos como quiera; no esta restringido a tener un Number como 
argumento de la parte izquierda. asi que si ve: 

1 - a 

puede convertir el primer argumento a Number usando el constructor. 

A veces querra ser capaz de restringir el uso de sus operadores haciendolos me- 
todos. Por ejemplo, cuando multiplique una matriz por un vector, el vector debe ir 
a la derecha. Pero si quiere que sus operadores sean capaces de convertir cualquier 
argumento, haga el operador una funcion friend. 

Afortunadamente, el compilador cogera la expresion 1-1 y convertira ambos ar¬ 
gumentos a objetos Number y despues llamara a operator-. Eso significaria que 
el codigo C existente podria empezar a funcionar de forma diferente. El compilador 
intenta primero la correspondencia «mas simple», es decir, en este caso el operador 
incorporado para la expresion 1 -1. 
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12.6.3. Ejemplo de conversion de tipos 

Un ejemplo en el que la conversion automatica de tipos es extremadamente util 
es con cualquier clase que encapsule una cadena de caracteres (en este caso, simple- 
mente implementaremos la clase usando la clase estandar de C++ string dado que 
es simple). Sin la conversion automatica de tipos, si quiere usar todas las funciones 
existentes de string de la libreria estandar de C, tiene que crear un metodo para cada 
una, asi: 

//: C12:Stringsl.cpp 
//No auto type conversion 

#include "../require.h" 

#include <cstring> 

#include <cstdlib> 

#include <string> 
using namespace std; 

class Stringc { 
string s; 

public: 

Stringc (const strings str = "") : s(str) {} 

int strcmp (const StringcS S) const { 

return ::strcmp(s.c_str(), S.s.c_str()); 

} 

// ... etc., for every function in string.h 

} ; 

int main() { 

Stringc si("hello"), s2("there"); 
si.strcmp(s2); 

} ///:~ 


Aqui, solo se crea la funcion strcmp (), pero tendria que crear las funciones co- 
rrespondientes para cada una de < cstr ing> que necesite. Afortunadamente, puede 
proporcionar una conversion automatica de tipos permitiendo el acceso a todas las 
funciones de <cstring>. 

//: C12:Strings2.cpp 
// With auto type conversion 

#include "../require.h" 

#include <cstring> 

#include <cstdlib> 

#include <string> 
using namespace std; 

class Stringc { 
string s; 

public: 

Stringc (const strings str = "") : s(str) {} 

operator const char*() const { 
return s.c_str(); 

} 

} ; 


int main () { 
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Stringc si ("hello"), s2 ("there"); 
strcmp(sl, s2); // Standard C function 
strspn(sl, s2); // Any string function! 
} ///:- 


Ahora cualquier funcion que acepte un argumento char 5 ’' puede aceptar tambien 
un argumento Stringc porque el compilador sabe como crear un char* a partir de 

Stringc. 


12.6.4. Las trampas de la conversion automatica de tipos 

Dado que el compilador debe decidir como realizar una conversion de tipos, pue¬ 
de meterse en problemas si el programador no disena las conversiones correctamen- 
te. Una situacion obvia y simple sucede cuando una clase X que puede convertirse a 
si misma en una clase Y con un operator Y ( ). Si la clase Y tiene un constructor que 
toma un argumento simple de tipo X, esto representa la conversion de tipos identica. 
El compilador ahora tiene dos formas de ir de X a Y, asi que se generara una error de 
ambigiiedad: 

//: C12:TypeConversionAmbiguity.cpp 
class Orange; // Class declaration 

class Apple { 
public: 

operator Orange() const; // Convert Apple to Orange 

} ; 


class Orange { 
public: 

Orange(Apple); // Convert Apple to Orange 

} ; 


void f(Orange) {} 

int main() { 

Apple a; 

//! f (a); // Error: ambiguous conversion 

} ///:~ 


La solucion obvia a este problema es no hacerla. Simplemente proporcione una 
ruta unica para la conversion automatica de un tipo a otro. 

Un problema mas dificil de eliminar sucede cuando proporciona conversiones 
automaticas a mas de un tipo. Esto se llama a veces acomodamiento (FIXME): 

//: C12:TypeConversionFanout.cpp 

class Orange {}; 
class Pear {}; 

class Apple { 
public: 

operator Orange() const; 
operator Pear() const; 
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// Overloaded eat () : 

void eat(Orange); 
void eat(Pear); 

int main() { 

Apple c; 

//! eat(c); 

// Error: Apple -> Orange or Apple -> Pear ??? 
} ///:- 


La clase Apple tiene conversiones automaticas a Orange y a Pear. El elemento 
capcioso aqui es que no hay problema hasta que alguien inocentemente crea dos 
versiones sobrecarga das de eat (). (Con una unica version el codigo en main () 
funciona correctamente). 

De nuevo la solucion — y el lema general de la conversion automatica de tipos — 
es proporcionar solo una conversion automatica de un tipo a otro. Puede tener con¬ 
versiones a otros tipos, solo que no deberian ser automaticas. Puede crear llamadas a 
funciones explicitas con nombres como makeA () y makeB (). 

Actividades ocultas 

La conversion automatica de tipos puede producir mas actividad subyacente de 
la que se podria esperar. Mire esta modification de CopyingVsInitialization . 
cpp como un pequeno rompecabezas: 

//: C12:CopyingVsInitialization2.cpp 

class Fi { } ; 

class Fee { 
public: 

Fee (int) {} 

Fee (const Fi& ) { } 

} ; 


class Fo { 
int i; 
public: 

Fo (int x = 0) : i (x) { } 

operator Fee () const { return Fee(i); } 

} ; 


int main () { 

Fo fo; 

Fee fee = fo; 

} ///:- 


No hay un constructor para crear Fee fee de un objeto Fo. Sin embargo, F- 
o tiene una conversion automatica de tipos a Fee. No hay un constructor de copia 
para crear un Fee a partir de un Fee, pero esa es una de las funciones especiales que 
el compilador puede crear. (El constructor por defecto, el constructor de copia yo- 
perator=) y el destructor pueden sintetizarse automaticamente por el compilador. 
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Asi que, para la relativamente inocua expresion: 

Fee fee = fo; 

se invoca el operador de conversion automatico de tipo, y se crea un constructor 
de copia. 

Use la conversion automatica de tipos con precaucion. Como con toda la sobre- 
carga de operadores, es excelente cuando reduce la tarea de codificacion significati- 
vamente, pero no vale la pena usarla de forma gratuita. 


12.7. Resumen 

El motivo de la existencia de la sobrecarga de operadores es para aquellas situa- 
ciones en la que la vida. No hay nada particularmente magico en ello; los operadores 
sobrecargados son solo funciones con nombres divertidos, y el compilador realiza las 
invocaciones a esas funciones cuando aparece el patron adecuado. Pero si la sobre¬ 
carga de operadores no proporciona un beneficio significativo el creador de la clase 
o para el usuario de la clase, no complique el asunto anadiendolos. 


12.8. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Cree una clase sencilla con un operador sobrecarga do ++. Intente llamar a este 
operador en la forma prefija y postfija y vea que clase de advertencia obtiene 
del compilador. 

2. Cree una clase sencilla que contenga un int y sobrecargue el operador + como 
un metodo. Cree tambien un metodo print () que tome un ostream?, como 
un argumento y lo imprima a un ostreamS. Pruebe su clase para comprobar 
que funciona correctamente. 

3. Anada un operador binario - al ejercicio 2 como un metodo. Demuestre que 
puede usar sus objetos en expresiones complejas como a + b -c. 

4. Anada un operador ++ y otro — al ejercicio 2, ambos con las versiones pre- 
fijas y postfijas, tales que devuelvan el objeto incrementado o decrementado. 
Asegurese de que la version postfija devuelve el valor correcto. 

5. Modifique los operadores de incremento y decremento del ejercicio 4 para que 
la version prefija devuelva una referencia no const y la postfija devuelva un 
objeto const. Muestre que funcionan correctamente y explique porque esto se 
puede hacer en la practica. 

6. Cambie la funcion print () del ejercicio2 para que use el operador sobrecar- 
gado << como en IostreamOperatorOverloading. cpp. 

7. Modifique el ejercicio 3 para que los operadores + y - no sean metodos. De¬ 
muestre que todavia funcionan correctamente. 

8. Anada el operador unario - al ejercicio 2 y demuestre que funciona correcta¬ 
mente. 
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9. Cree una clase que contenga un unico private char. Sobrecargue los operadores 
de flujos de entrada/salida << y >> (como en IostreamOperatorOverloading. 
opp) y pruebelos. Puede probarlos con f streams, stringstreams y cin y 
cout. 

10. Determine el valor constante ficticio que su compilador pasa a los operadores 
postfijos ++ y —. 

11. Escriba una clase Number que contenga un double y anada operadores sobre- 

cargados para +, *, / y la asignacion. Elija los valores de retorno para estas 

funciones para que las expresiones se puedan encadenar y que sea eficiente. 
Escriba una conversion automatica de tipos operator int(). 

12. Modifique el ejercicio 11 para que use la optimization del valor de retorno, si to- 
davia no lo ha hecho. 

13. Cree una clase que contenga un puntero, y demuestre que si permite al compi¬ 
lador sintetizar el operador = el resultado de usar ese operador seran punteros 
que estaran solapados en la misma ubicacion de memoria. Ahora arregle el 
problema definiendo su propio operador = y demuestre que corrige el sola- 
pamiento. Asegurese que comprueba la auto-asignacion y que maneja el caso 
apropiadamente. 

14. Escriba una clase llamada Bird que contenga un miembro string y un static int. 

En el constructor por defecto, use el int para generar automaticamente un iden- 
tificador que usted construya en el string junto con el nombre de la clase(Bird 
#1, Bird #2, etc). Anada un operador <; < para flujos de salida para impri- 
mir los objetos Bird-Escriba un operador de asignacion = y un constructor de 
copia. En main () veriflque que todo funciona correctamente. 

15. Escriba una clase llamada BirdHouse que contenga un objeto, un puntero y 
una referencia para la clase Bird del ejercicio 14. El constructor deberia tomar 
3 Birds como argumentos. Anada un operador << de flujo de salida para B- 
irdHouse. Deshabilite el operador de asignacion = y el constructor de copia. 

En main () veriflque que todo funciona correctamente. 

16. Anada un miembro de datos int a Bird y a BirdHouse en el ejercicio 15. 
Anada operadores miembros * y / que usen el miembro int para realizar 
las operaciones en los respectivos miembros. Veriflque que funcionan. 

17. Repita el ejercicio 16 usando operadores no miembro. 

18. Anada un operador - a SmartPointer. cpp y a NestedSmartPointer. 
cpp. 

19. Modifique CopyingVsInitialization. cpp para que todos los construc- 
tores impriman un mensaje que explique que esta pasando. Ahora veriflque 
que las dos maneras de llamar al constructor de copia (la de asignacion y la de 
parentesis) son equivalentes. 

20. Intente crear un operador no miembro = para una clase y vea que clase de 
mensaje del compilador recibe. 

21. Cree una clase con un operador de asignacion que tenga un segundo argumen- 
to, un string que tenga un valor por defecto que diga op = call.Creeuna 
funcion que asigne un objeto de su clase a otro y muestre que su operador de 
asignacion es llamado correctamente. 
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22. En CopyingWithPointers . cpp elimine eloperador = en DogHouse ymues- 
tre que el operador = sintetizado por el compilador copia correctamente str¬ 
ing pero es simplemente un alias del puntero Dog. 

23. En Ref erenceCounting. cpp anada un static int y un int ordinario como 
atributos a Dog y a DogHouse. En todos los constructores para ambas clases, 
incremente el static int y asigne el resultado al int ordinario para mantener un 
seguimiento del numero de objetos que estan siendo creados. Haga las modi- 
ficaciones necesarias para que todas las sentencias de impresion muestren los 
identificadores int de los objetos involucrados. 

24. Cree una clase que contenga un string como atributo. Inicialice el stri¬ 
ng en el constructor, pero no cree un constructor de copia o un operador =. 
Haga una segunda clase que tenga un atributo de su primera clase; no cree un 
constructor de copia o un operador = para esta clase tampoco. Demuestre que 
el constructor de copia y el operador = son sintetizados correctamente por el 
compilador. 

25. Combine las clases en OverloadingUnaryOperators . cpp y en Integer . 
cpp. 

26. Modifique PointerToMemmberOperator . cpp anadiendo dos nuevas fun- 
ciones miembro a Dog que no tomen argumentos y devuelvan void. Cree y 
compruebe un operador sobrecargado ->* que funcione con sus dos nuevas 
funciones. 

27. Anada un operador ->* a NestedSmartPointer . cpp. 

28. Cree dos clases, Apple y Orange. En Apple, cree un constructor que tome 
una Orange como argumento. Cree una funcion que tome un Apple y llame 
a esa funcion con una una Orange para demostrar que funciona. Ahora haga 
explicito el constructor de Apple para demostrar que asi se evita la conversion 
automatica de tipos. Modifique la llamada a su funcion para que la la conver¬ 
sion se haga explicitamente y de ese modo, funcione. 

29. Anada un operador global * a Ref lexivitylnOver loading. cpp y demues¬ 
tre que es reflexivo. 

30. Cree dos clases y un operador + y las funciones de conversion de tal manera 
que la adiccion sea reflexiva para las dos clases. 

31. Arregle TypeConversionFanout . cpp creando una funcion explicita para 
realizar la conversion de tipo, en lugar de uno de los operadores de conversion 
automaticos. 

32. Escriba un codigo simple que use los operadores +, -, *, / para double. Ima¬ 
gine como el compilador genera el codigo ensamblador y mire el ensamblador 
que se genera en realidad para descubrir y explicar que esta ocurriendo «bajo 
el capo». 
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13: Creacion dinamica de objetos 

A veces se conoce la cantidad exacta exacta, el tipo y duracion de 
la vida de los objetos en un programa, pero no siempre es asf. 

^Cuantos aviones tendra que supervisar un sistema de control de trafico aereo? 
^Cuantas formas o figuras se usaran en un sistema CAD? ^Cuantos nodos habra en 
una red? 

Para resolver un problema general de programacion, es esencial poder crear y 
destruir objetos en tiempo de ejecucion. Por supuesto, C proporciona las funciones 
de asignacion dinamica de memoria malloc () y sus variantes, y free (), que per- 
miten obtener y liberar bloques en el espacio de memoria del monticulo (tambien 
llamado espacio libre 1 mientras se ejecuta el programa. 

Este metodo sin embargo, no funcionara en C++. El constructor no le permite 
manipular la direccion de memoria a inicializar, y con motivo. De permitirse, seria 
posible: 

1. Olvidar la llamada al constructor. Con lo cual no seria posible garantizar la 
inicializacion de los objetos en C++. 

2. Usar accidentalmente un objeto que aun no ha sido inicializado, esperando que 
todo vaya bien. 

3. Manipular un objeto de tamano incorrecto. 

Y por supuesto, incluso si se hizo todo correctamente, cualquiera que modifique 
el programa estaria expuesto a cometer esos mismos errores. Una gran parte de los 
problemas de programacion tienen su origen en la inicializacion incorrecta de obje¬ 
tos, lo que hace especialmente importante garantizar la llamada a los constructores 
para los objetos que han de ser creados en el monticulo. 

^Como se garantiza en C++ la correcta inicializacion y limpieza, permitiendo la 
creacion dinamica de objetos? 

La respuesta esta en integrar en el lenguaje mismo la creacion dinamica de obje¬ 
tos. malloc () y free () son funciones de biblioteca y por tanto, estan fuera del 
control del compilador. Si se dispone de un operador que lleve a cabo el acto combina- 
do de la asignacion dinamica de memoria y la inicializacion, y de otro operador que 
realice el acto combinado de la limpieza y de liberacion de memoria, el compilador 
podra garantizar la llamada a los constructores y destructores de los objetos. 

En este capitulo vera como se resuelve de modo elegante este problema con los 
operadores new y delete de C++. 

1 N.T. espacio de almacenamiento libre (free store) 
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13.1. Creadon de objetos 

La creacion de un objeto en C++ tiene lugar en dos pasos: 

1. Asignacion de memoria para el objeto. 

2. Llamada al constructor. 

Aceptemos por ahora que este segundo paso ocurre siempre. C++ lo fuerza, de- 
bido a que el uso de objetos no inicializados es una de las causas mas frecuentes 
de errores de programacion. Siempre se invoca al constructor, sin importar como ni 
donde se crea el objeto. 

El primero de estos pasos puede ocurrir de varios modos y en diferente momento: 

1. Asignacion de memoria en la zona de almacenamiento estatico, que tiene lugar 
durante la carga del programa. El espacio de memoria asignado al objeto existe 
hasta que el programa termina. 

2. Asignacion de memoria en la pila, cuando se alcanza algun punto determina- 
do durante la ejecucion del programa (la Have de apertura de un bloque). La 
memoria asignada se vuelve a liberar de forma automatica en cuanto se alcan¬ 
za el punto de ejecucion complementario (la Have de cierre de un bloque). Las 
operaciones de manipulation de la pila forman parte del conjunto de instruc- 
ciones del procesador y son muy eficientes. Por otra parte, es necesario saber 
cuantas variables se necesitan mientras se escribe el programa de modo que el 
copilador pueda generar el codigo correspondiente. 

3. Asignacion dinamica, en una zona de memoria libre llamada monticulo (heap 
o free store). Se reserva espacio para un objeto en esta zona mediante la llamada 
a una funcion durante la ejecucion del programa; esto significa que se puede 
decidir en cualquier momento que se necesita cierta cantidad de memoria. Esto 
conlleva la responsabilidad de determinar el momento en que ha de liberarse 
la memoria, lo que implica determinar el tiempo de vida de la misma que, por 
tanto, ya no esta bajo control de las reglas de ambito. 

A menudo, las tres regiones de memoria referidas se disponen en una zona con- 
tigua de la memoria fisica: area estatica, la pila, y el monticulo, en un orden determi- 
nado por el escritor del compilador. No hay reglas fijas. La pila puede estar en una 
zona especial, y puede que las asignaciones en el monticulo se obtengan median- 
te petition de bloques de la memoria del sistema operativo. Estos detalles quedan 
normalmente ocultos al programador puesto que todo lo que se necesita conocer al 
respecto es que esa memoria estara disponible cuando se necesite. 


13.1.1. Asignacion dinamica en C 

C proporciona las funciones de su biblioteca estandar malloc () y sus variantes 
calloc () y realloc () para asignar, y free () para liberar bloques de memoria 
dinamicamente en tiempo de ejecucion. Estas funciones son pragmaticas pero rudi- 
mentarias por lo que requieren comprension y un cuidadoso manejo por parte del 
programador. El listado que sigue es un ejemplo que ilustra el modo de crear una 
instancia de una clase con estas funciones de C: 


//: C13:MallocClass.cpp 
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// Malloc with class objects 

// What you'd have to do if not for "new" 

#include /require.h" 

#include <cstdlib> // malloc() & free() 

#include <cstring> // raemset() 

#include <iostream> 

using namespace std; 

class Obj { 

int i, j, k ; 
enum { s z = 10 0 }; 
char buf[sz]; 
public: 

void initialize() { // Can't use constructor 

cout << "initializing Obj" << endl; 
i = j = k = 0; 
raemset(buf, 0, sz); 

} 

void destroy)) const { // Can't use destructor 
cout << "destroying Obj" << endl; 


} ; 


int main() { 

Obj* obj = (Obj*)malloc(sizeof(Obj)); 
require(obj != 0); 
obj->initialize(); 

// ... sometime later: 
obj->destroy(); 
free(obj); 

} // / : ~ 


Observe el uso de malloc () para la obtencion de espacio para el objeto: 

Obj* obj = (Obj*)malloc(sizeof(Obj)); 

Se debe pasar como parametro a malloc () el tamano del objeto. El tipo de re- 
torno de malloc () es void’ 1 ', pues es solo un puntero a un bloque de memoria, no 
un objeto. En C++ no se permite la asignacion directa de un void’ 1 ' a ningun otro tipo 
de puntero, de ahl la necesidad de la conversion expllcita de tipo (molde). 

Puede ocurrir que malloc () no encuentre un bloque adecuado, en cuyo caso 
devolvera un puntero nulo, de ahl la necesidad de comprobar la validez del puntero 
devuelto. 

El principal escollo esta en la llnea: 

obj->initialize(); 

El usuario debera asegurarse de inicializar el objeto antes de su uso. Observese 
que no se ha usado el constructor debido a que este no puede ser llamado de modo 
expllcito 2 ; es llamado por el compilador cuando se crea un objeto. El problema es 

2 Existe una sintaxis especial llamada placement-new que permite llamar al constructor para un bloque 
de memoria preasignando. Se vera mas adelante, en este mismo capitulo. 
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que el usuario puede olvidar inicializar el objeto antes de usarlo, introduciendo as! 
una importante fuente de problemas. 

Como consecuencia, muchos programadores encuentran muy confusas y com- 
plicadas las funciones de asignacion dinamica de la memoria en C. No es muy dificil 
encontrar programadores que, usando maquinas con memoria virtual, usan vecto- 
res enormes en el area de almacenamiento estatico para evitar tener que tratar con la 
asignacion dinamica. Dado que C++ intenta facilitar el uso de la biblioteca a los pro¬ 
gramadores ocasionales, no es aceptable la forma de abordar la asignacion dinamica 
en C. 


13.1.2. El operador new 

La solucion que ofrece C++ consiste en combinar la serie de acciones necesarias 
para la creacion de un objeto en un unico operador llamado >new. Cuando se crea 
un objeto mediante el operador >new, este se encarga de obtener el espacio necesario 
para el objeto y de llamar a su constructor. Cuando se ejecuta el codigo: 

MyType *fp = new MyType(l,2); 


se asigna espacio mediante alguna llamada equivalente a >malloc (sizeof (M- 
yType ) ) —con frecuencia es asi, literalmente—, y usando la direccion obtenida como 
puntero >this,y (1, 2) como argumentos, se llama al constructor de la clase M- 
yType. Para cuando esta disponible, el valor de retorno de new es ya un puntero 
valido a un objeto inicializado. Ademas es del tipo correcto, lo que hace innecesaria 
la conversion. 

El operador new por defecto, comprueba el exito o fracaso de la asignacion de 
memoria como paso previo a la llamada al constructor, haciendo innecesaria y re- 
dundante la posterior comprobacion. Mas adelante en este capitulo se vera que su- 
cede si se produce este fallo. 

En las expresiones con new se puede usar cualquiera de los constructores dispo- 
nibles para una clase. Si este no tiene argumentos, se escribe la expresion sin lista de 
argumentos 

MyType *fp = new MyType; 


Es notable la simpleza alcanzada en la creacion dinamica de objetos: una unica 
expresion realiza todo el trabajo de calculo de tamano, asignacion, comprobaciones 
de seguridad y conversion de tipo. Esto hace que la creacion dinamica de objetos sea 
tan sencilla como la creacion en la pila. 


13.1.3. El operador delete 

El complemento a la expresion new es la expresion delete, que primero llama al 
destructor y despues libera la memoria (a menudo mediante una llamada a free (- 
)). El argumento para una expresion con delete debe ser una direccion: un puntero 
a objeto creado mediante new. 

delete fp; 
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Esta expresion destruye el objeto y despues libera el espacio dinamicamente asig- 
nado al objeto MyType 

El uso del operador delete debe limitarse a los objetos que hayan sido crea- 
dos mediante new. Las consecuencias de aplicar el operador delete a los objetos 
creados con malloc (), calloc () o realloc () no estan definidas. Dado que la 
mayoria de las implementaciones por defecto de new y delete usan malloc () y 
free (), el resultado sera probablemente la liberacion de la memoria sin la llamada 
al destructor. 

No ocurre nada si el puntero que se le pasa a delete es nulo. Por esa razon, 
a menudo se recomienda asignar cero al puntero inmediatamente despues de usar 
delete; se evita as! que pueda ser usado de nuevo como argumento para delete. 
Tratar de destruir un objeto mas de una vez es un error de consecuencias imprevisi- 
bles. 


13.1.4. Un ejemplo sencillo 

El siguiente ejemplo demuestra que la inicializacion tiene lugar: 

//: C13:Tree.h 

#ifndef TREE_H 
#define TREE_H 
#include <iostream> 

class Tree { 
int height; 

public: 

Tree (int treeHeight) : height(treeHeight) {} 

-Tree() { std::cout << } 

friend std::ostreamS 

operator« (std::ostream& os, const Tree* t) { 
return os << "Tree height is: " 

<< t->height << std::endl; 


#endif // TREE_H ///:- 


Se puede probar que el constructor es invocado imprimiendo el valor de Tre- 
e. Aqui se hace sobrecargando el operator << para usarlo con un ostream y 
un Tree*. Note, sin embargo, que aunque la funcion esta declarada como friend, 
esta definida como una inline!. Esto es as! por conveniencia —definir una funcion 
amiga como inline a una clase no cambia su condicion de amiga o el hecho de que 
es una funcion global y no un metodo. Tambien resaltar que el valor de retorno es el 
resultado de una expresion completa (el ostream&), y as! debe ser, para satisfacer el 
tipo del valor de retorno de la funcion. 


13.1.5. Trabajo extra para el gestor de memoria 

Cuando se crean objetos automaticos en la pila, el tamano de los objetos y su 
tiempo de vida queda fijado en el codigo generado, porque el compilador conoce su 
tipo, cantidad y alcance. Crear objetos en el monticulo implica una sobrecarga adicio- 
nal, tanto en tiempo como en espacio. Veamos el escenario tlpico (Puede reemplazar 
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mallocO concallocO o realloc ()). 

Se invoca malloc (), que pide un bloque de memoria. (Este codigo realmente 
puede ser parte de malloc ()). 

Ahora tiene lugar la busqueda de un bloque de tamano adecuado de entre los 
bloques libres. Esto requiere la comprobacion de un mapa o directorio de algun ti- 
po que lleve el registro de los bloques disponibles y de los que estan en uso. Es un 
proceso rapido, pero puede que necesite varias pruebas, es pues un proceso no deter- 
minista. Dicho de otro modo, no se puede contar con que malloc () tarde siempre 
exactamente el mismo tiempo en cada busqueda. 

Antes de entregar el puntero del bloque obtenido, hay que registrar en alguna 
parte su tamano y localizacion para que malloc () no lo vuelva a usar y para que 
cuando se produzca la llamada a free (), el sistema sepa cuanto espacio ha de libe- 
rar. 

El modo en que se implementan todas estas operaciones puede variar mucho. 
No hay nada que impida que puedan implementarse las primitivas de asignacion 
de memoria en el conjunto de instrucciones del procesador. Si es suficientemente cu- 
rioso, pueden escribir programas que permitan averiguar como esta implementada 
malloc (). Si dispone de el, puede leer el codigo fuente de la biblioteca de funciones 
de C, si no, siempre esta disponible el de GNU C. 


13.2. Rediseno de los ejemplos anteriores 

Puede reescribirse el ejemplo Stash que vimos anteriormente en el libro, ha- 
ciendo uso de los operadores new y delete, con las caracteristicas que se han visto 
desde entonces. A la vista del nuevo codigo se pueden repasar estas cuestiones. 

Hasta este punto del libro, ninguna de las clases Stash ni Stack poseeran los 
objetos a los que apuntan; es decir, cuando el objeto Stash o Stack sale de ambito, 
no se invoca delete para cada uno de los objetos a los que apunta. La razon por la 
que eso no es posible es porque, en un intento de conseguir mas generalidad, utilizan 
punteros void. Usar delete con punteros void libera el bloque de memoria pero, 
al no existir informacion de tipo, el compilador no sabe que destructor debe invocar. 


13.2.1. delete void* probablemente es un error 

Es necesario puntualizar que, llamar a delete con un argumento void* es casi 
con seguridad un error en el programa, a no ser que el puntero apunte a un objeto 
muy simple; en particular, que no tenga un destructor. He aqui un ejemplo ilustrati- 
vo: 

//: C13:BadVoidPointerDeletion.cpp 

// Deleting void pointers can cause memory leaks 

#include <iostream> 

using namespace std; 

class Object { 

void* data; // Some storage 

const int size; 
const char id; 
public: 

Object (int sz, char c) : size(sz), id(c) { 
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data = new char [size]; 

cout << "Constructing object " << id 
<< ", size = " << size << endl; 

} 

-Object() { 

cout << "Destructing object " << id << endl; 
delete []data; // OK, just releases storage, 
// no destructor calls are necessary 


} ; 


int main () { 

Object* a = new Object(40, 'a'); 

delete a; 

void* b = new Object(40, 'b'); 

delete b; 

} ///:~ 


La clase Object contiene la variable data de tipo void* que es inicializada para 
apuntar a un objeto simple que no tiene destructor. En el destructor de Object se 
llama a delete con este puntero, sin que tenga consecuencias negativas puesto que 
lo unico que se necesita aqui es liberar la memoria. 

Ahora bien, se puede ver en main () la necesidad de que delete conozca el tipo 
del objeto al que apunta su argumento. Esta es la salida del programa: 


Construyendo objeto a, ntamao = 40 
Destruyendo objeto a 
Construyendo objeto b, ntamao = 40 


Como delete sabe que a es un puntero a Object, se lleva a cabo la llamada al 
destructor de Object, con lo que se libera el espacio asignado a data. En cambio, 
cuando se manipula un objeto usando un void*, como es el caso en delete b, se 
libera el bloque de Object, pero no se efectua la llamada a su destructor, con lo que 
tampoco se liberara el espacio asignado a data, miembro de Ob ject. Probablemen- 
te no se mostrara ningun mensaje de advertencia al compilar el programa; no hay 
ningun error sintactico. Como resultado obtenemos un programa con una silenciosa 
fuga de memoria. 

Cuando se tiene una fuga de memoria, se debe buscar entre todas las llamadas 
a delete para comprobar el tipo de puntero que se le pasa. Si es un void*, puede 
estar ante una de las posibles causas (Sin embargo, C++ proporciona otras muchas 
oportunidades para la fuga de memoria). 


13.2.2. Responsabilidad de la limpieza cuando se usan pun- 
teros 

Para hacer que los contenedores Stack y Stash sean flexibles, capaces de recibir 
cualquier tipo de objeto, se usan punteros de tipo void*. Esto hace necesario convertir 
al tipo adecuado los punteros devueltos por las clases Stash y Stack, antes de 
que sean usados. Hemos visto en la seccion anterior, que los punteros deben ser 
convertidos al tipo correcto incluso antes de ser entregados a delete, para evitar 
posibles fugas de memoria. 

Hay otro problema, derivado de la necesidad de llamar a delete para cada pun- 
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tero a objeto almacenado en el contenedor. El contenedor no puede realizar la lim- 
pieza para los punteros que almacena puesto que son punteros void*. Esto puede 
derivar en un serio problema si a un contenedor se le pasan punteros a objetos auto- 
maticos junto con punteros a objetos dinamicos; el resultado de usar delete sobre 
un puntero que no haya sido obtenido del monticulo es imprevisible. Mas aun, al 
obtener del contenedor un puntero cualquiera, existiran dudas sobre el origen, au- 
tomatico, dinamico o estatico, del objeto al que apunta. Esto implica que hay que 
asegurarse del origen dinamico de los punteros que se almacenen en la siguiente 
version de Stashy Stack, bien sea mediante una programacion cuidadosa, o bien 
por la creacion de clases que solo puedan ser construidas en el monticulo. 

Es muy importante asegurarse tambien de que el programador cliente se res- 
ponsabilice de la limpieza de los punteros del contenedor. Se ha visto en ejemplos 
anteriores que la clase Stack comprobaba en su destructor que todos los objetos 
Link habian sido desapilados. Un objeto Stash para punteros requiere un modo 
diferente de abordar el problema. 


13.2.3. Stash para punteros 

Esta nueva version de la clase Stash, que llamamos P St ash, almacena punteros 
a objetos existentes en el monticulo, a diferencia de la vieja version, que guardaba 
una copia por valor de los objetos. Usando new y delete, es facil y seguro almace- 
nar punteros a objetos creados en el monticulo. 

He aqui el archivo de cabecera para «Stash para punteros»: 

//: C13:PStash.h 

// Holds pointers instead of objects 

#ifndef PSTASH_H 
#define PSTASH_H 

class PStash { 

int quantity; // Number of storage spaces 
int next; // Next empty space 
// Pointer storage: 

void** storage; 

void inflate (int increase); 

public: 

PStash() : quantity(0), storage(0), next(0) {} 

-PStash (); 

int add (void* element); 

void* operator!](int index) const; // Fetch 
// Remove the reference from this PStash: 
void* remove (int index); 

// Number of elements in Stash: 

int count () const { return next; } 

} ; 

#endif // PSTASH_H ///:- 


Los elementos de datos subyacentes no han cambiado mucho, pero ahora el al- 
macenamiento se hace sobre un vector de punteros void, que se obtiene mediante 
new en lugar de malloc (). En la expresion 


void** st = new void*[ quantity + increase ]; 



'Volumenl" — 2012/1/12 — 13:52 — page 385 — #423 


13.2. Rediseno de los ejemplos anteriores 


se asigna espacio para un vector de punteros a void. 

El destructor de la clase libera el espacio en el que se almacenan los punteros 
sin tratar de borrar los objetos a los que hacen referenda, ya que esto, insistimos, 
liberaria el espacio asignado a los objetos, pero no se produciria la necesaria llamada 
a sus destructores por la falta de informacion de tipo. 

El otro cambio realizado es el reemplazo de la funcion fetch () por operator 
[ ], mas significativo sintacticamente. Su tipo de retorno es nuevamente void*, por 
lo que el usuario debera recordar el tipo de los objetos a que se refieren y efectuar 
la adecuada conversion al extraerlos del contenedor. Resolveremos este problema en 
capitulos posteriores. 

Sigue la definicion de los metodos de PStash: 

//: C13:PStash.cpp {0} 

// Pointer Stash definitions 

#include "PStash.h" 

#include "../require.h" 

#include <iostream> 

#include <cstring> // 'mem' functions 

using namespace std; 

int PStash::add (void* element) { 
const int inflateSize = 10; 
if (next >= quantity) 
inflate(inflateSize) ; 
storage[next++] = element; 
return (next - 1); // Index number 

} 


// No ownership: 

PStash::-PStash() { 

for(int i = 0; i < next; i++) 
require(storage[i] == 0, 
"PStash not cleaned up"); 
delete []storage; 

} 


// Operator overloading replacement for fetch 

void* PStash:: operator[](int index) const { 
require(index >= 0, 

"PStash::operator[] index negative"); 
if (index >= next) 

return 0; //To indicate the end 
// Produce pointer to desired element: 
return storage[index]; 


void* PStash::remove (int index) { 
void* v = operator!] (index); 

// "Remove" the pointer: 

if (v != 0) storage[index] = 0; 

return v; 

} 


void PStash::inflate (int increase) { 

const int psz = sizeof(void*); 

void** st = new void* [quantity + increase]; 
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memset(st, 0, (quantity + increase) * psz); 
memcpy(st, storage, quantity * psz); 
quantity += increase; 
delete []storage; // Old storage 
storage = st; // Point to new memory 
} ///:- 


La funcion add () es, en efecto, la misma que antes si exceptuamos el hecho de 
que lo que se almacena ahora es un puntero a un objeto en lugar de una copia del 
objeto. 

El codigo de inf late ( ) ha sido modificado para gestionar la asignacion de me- 
moria para un vector de void*, a diferencia del diseno previo, que solo trataba con 
bytes. Aqui, en lugar de usar el metodo de copia por el mdice del vector, se pone 
primero a cero el vector usando la funcion memset ( ) de la biblioteca estandar de 
C, aunque esto no sea estrictamente necesario ya que, presumiblemente, P St ash 
manipulara la memoria de forma adecuada, pero a veces no es muy costoso anadir 
un poco mas de seguridad. A continuacion, se copian al nuevo vector usando m- 
emcpy () los datos existentes en el antiguo. Con frecuencia vera que las funciones 
memcpy () y memset () han sido optimizadas en cuanto al tiempo de proceso, de 
modo que pueden ser mas rapidas que los bucles anteriormente vistos. No obstan¬ 
te, una funcion como inf late () no es probable que sea llamada con la frecuencia 
necesaria para que la diferencia sea palpable. En cualquier caso, el hecho de que 
las llamadas a funcion sean mas concisas que los bucles, puede ayudar a prevenir 
errores de programacion. 

Para dejar definitivamente la responsabilidad de la limpieza de los objetos so- 
bre los hombros del programador cliente, se proporcionan dos formas de acceder a 
los punteros en PStash: el operador [ ], que devuelve el puntero sin eliminarlo del 
contenedor, y un segundo metodo remove ( ) que ademas de devolver el puntero lo 
elimina del contenedor, poniendo a cero la posicion que ocupaba. Cuando se produ¬ 
ce la llamada al destructor de PStash, se prueba si han sido previamente retirados 
todos los punteros, si no es asi, se notifica, de modo que es posible prevenir la fuga 
de memoria. Se veran otras soluciones mas elegantes en capitulos posteriores. 

Una prueba 

Aqui aparece el programa de prueba de Stash, reescrito para PStash: 

//: C13:PStashTest.cpp 
//{L} PStash 

// Test of pointer Stash 

#include "PStash.h" 

#include /require.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

int main() { 

PStash intStash; 

// 'new' works with built-in types, too. Note 
// the "pseudo-constructor" syntax: 
for (int i = 0; i < 25; i++) 
intStash.add(new int(i)); 
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for(int j = 0; j < intStash.count(); j++) 
cout << "intStash[" << j << "] = " 

<< * (int*) intStash[j] << endl; 

// Clean up: 

for(int k = 0; k < intStash.count (); k++) 
delete intStash.remove(k); 
ifstream in ( "PStashTest.cpp"); 
assure(in, "PStashTest.cpp"); 

PStash stringStash; 
string line; 

while (getline(in, line)) 

stringStash.add (new string(line)); 

// Print out the strings: 

for(int u = 0; stringStash[u]; u++) 

cout << "stringStash[" << u << "] = " 

<< * (string*)stringStash[u] << endl; 

// Clean up: 

for(int v = 0; v < stringStash.count(); v++) 
delete (string*)stringStash.remove(v); 

} ///:~ 


Igual que antes, se crean y rellenan varias Stash, pero esta vez con los punteros 
obtenidos con new. En el primer caso, vease la linea: 

intStash.add(new int(i)); 


Se ha usado una forma de pseudo constructor en la expresion new int (i), 
con lo que ademas de crear un objeto int en el area de memoria dinamica, le asigna 
el valor inicial i. 

Para imprimir, es necesario convertir al tipo adecuado el puntero obtenido de 
PStash: : operator []; lo mismo se repite con el resto de los objetos de PSta- 
tsh del programa. Es la consecuencia indeseable del uso de punteros void como 
representation subyacente, que se corregira en capitulos posteriores. 

En la segunda prueba, se lee linea a linea el propio archivo fuente. Mediante g- 
etline () se lee cada linea de texto en una variable de cadena, de la que se crea 
una copia independiente. Si le hubieramos pasado cada vez la direction de lin- 
e, tendriamos un monton de copias del mismo puntero, referidas a la ultima linea 
leida. 

En, en la recuperation de los punteros, vera la expresion: 

*(string*)stringStash[v]; 


El puntero obtenido por medio de operator [ ] debe ser convertido a string* 
para tener el tipo adecuado. Despues el string* es de-referenciado y es visto por el 
compilador como un objeto string que se envia a cout. 

Antes de destruir los objetos, se han de eliminar las referencias correspondientes 
mediante el uso de remove (). De no hacerse asi, PStash notificara que no se ha 
efectuado la limpieza correctamente. Vease que en el caso de los punteros a int, no 
es necesaria la conversion de tipo al carecer de destructor, y lo unico que se necesita 
es liberar la memoria: 
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j delete intStash.remove(k); 

En cambio, para los punteros a string, hace falta la conversion de tipo, so pena de 
crear otra (silenciosa) fuga de memoria, de modo que el molde es esencial: 

j delete (string*) stringStash.remove(k); 

Algunas de estas dificultades pueden resolverse mediante el uso de plantillas, 
que veremos en el capitulo 16. FIXME:ref 

13.3. new y delete para vectores 

En C++ es igual de facil crear vectores de objetos en la pila o en el monticulo, con 
la certeza de que se producira la llamada al constructor para cada uno de los objetos 
del vector. Hay una restriction: debe existir un constructor por defecto, o sea, sin 
argumentos, que sera invocado para cada objeto. 

Cuando se crean vectores de objetos dinamicamente, usando new, hay otras cosas 
que hay que tener en cuenta. Como ejemplo de este tipo de vectores vease 


MyType* fp = new MyType[100]; 


Esta sentencia asigna espacio suficiente en el monticulo para 100 objetos MyType 
y llama al constructor para cada uno de ellos. Lo que se ha obtenido es simplemente 
un MyType’ 1 ', exactamente lo mismo que hubiera obtenido de esta otra forma, que 
crea un unico objeto: 

MyType* fp2 = new MyType; 


El escritor del programa sabe que fp es la direction del primer elemento de un 
vector, por lo que tiene sentido seleccionar elementos del mismo mediante una ex- 
presion como f p [ 3 ], pero <(que pasa cuando destruimos el vector?. Las sentencias 

delete fp2; // Correcta 

delete fp; // Esta no atendr el efecto deseado 


parecen iguales, y sus efectos seran los mismos. Se llamara al destructor del objeto 
MyType al que apunta el puntero dado y despues se liberara el bloque asignado. Esto 
es correcto para fp2, pero no lo es para fp, significa que los destructores de los 99 
elementos restantes del vector no se invocaran. Sin embargo, si se liberara toda la 
memoria asignada al vector, ya que fue obtenida como un unico gran bloque cuyo 
tamano quedo anotado en alguna parte por las rutinas de asignacion. 

Esto se soluciona indicando al compilador que el puntero que pasamos es la di¬ 
reccion de inicio de un vector, usando la siguiente sintaxis: 

delete [] fp; 


Los corchetes indican al compilador la necesidad de generar el codigo para obte- 
ner el numero de objetos en el vector, que fue guardado en alguna parte cuando se 
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creo, y llamar al destructor para cada uno de dichos elementos. Esta es una mejora 
sobre la sintaxis primitiva, que puede verse ocasionalmente en el codigo de viejos 
programas: 

delete [100] fp; 

que forzaba al programador a incluir el numero de objetos contenidos en el vec¬ 
tor, introduciendo con ello una posible fuente de errores. El esfuerzo adicional que 
supone para el compilador tener en esto en cuenta es pequeno, y por eso se considero 
preferible especificar el numero de objetos en un lugar y no en dos. 


13.3.1. Como hacer que un puntero sea mas parecido a un 
vector 

Como defecto colateral, existe la posibilidad de modificar el puntero f p anterior- 
mente definido, para que apunte a cualquier otra cosa, lo que no es consistente con 
el hecho de ser la direction de inicio de un vector. Tiene mas sentido definirlo como 
una constante, de modo que cualquier intento de modification sea senalado como 
un error. Para conseguir este efecto se podria probar con: 

int const* q = new int[10]; 

o bien: 

const int* q = new int[10]; 

pero en ambos casos el especificador const quedaria asociado al int, es decir, 
al valor al que apunta, en lugar de al puntero en si. Si se quiere conseguir el efecto 
deseado, en lugar de las anteriores, se debe poner: 

int* const q = new int[10]; 

Ahora es posible modificar el valor de los elementos del vector, siendo ilegal cual¬ 
quier intento posterior de modificar q, como q++ por ejemplo, al igual que ocurre con 
el identificador de un vector ordinario. 


13.3.2. Cuando se supera el espacio de almacenamiento 

^Que ocurre cuando new () no puede encontrar un bloque contiguo suficiente- 
mente grande para alojar el objeto? En este caso se produce la llamada a una funcion 
especial: el manejador de errores de new o new-handier. Para ello comprueba si un 
determinado puntero a funcion es nulo, si no lo es, se efectua la llamada a la funcion 
a la que apunta. 

El comportamiento por defecto del manejador de errores de new es disparar una 
exception, asunto del que se tratara en el Volumen 2. Si se piensa usar la asignacion 
dinamica, conviene al menos reemplazar el manejador de errores de new por una 
funcion que advierta de la falta de memoria y fuerce la termination del programa. 
De este modo, durante la depuration del programa, se podra seguir la pista de lo su- 
cedido. Para la version final del programa, sera mejor implementar una recuperation 
de errores mas elaborada. 
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La forma de reemplazar el manejador de new-handier por defecto consiste en in- 
duir el archivo new. h y hacer una llamada a la funcion set_new_handler () con 
la direccion de la funcion que se desea instalar: 

//: C13:NewHandler.cpp 
// Changing the new-handier 

#include <iostream> 

#include <cstdlib> 

#include <new> 
using namespace std; 

int count = 0; 

void out_of_memory() { 

cerr << "memory exhausted after " << count 
<< " allocations!" << endl; 
exit (1) ; 

} 


int main () { 

set_new_handler(out_of_memory); 

while (1) { 

count++; 

new int [1000]; // Exhausts memory 

} 

} ///: ~ 


La funcion a instalar debe retornar void y no to mar argumentos. El bucle wh¬ 
ile seguira pidiendo bloques de int hasta consumir la memoria libre disponible, 
sin hacer nada con ellos. Justo a la siguiente llamada a new, no habra espacio para 
asignar y se producira la llamada al manejador de new. 

Este comportamiento del new-handier esta asociado al operator new (), de mo- 
do que si se sobrecarga operator new () (asunto que se trata en la siguiente sec- 
cion), no se producira la llamada al manejador de new. Si se desea que se produzca 
dicha llamada sera necesario que lo haga en el operator new () que substituya al 
original. 

Por supuesto, es posible escribir manejadores new mas sofisticados, incluso al- 
guno que intente reclamar los bloques asignados que no se usan (conocidos habi- 
tualmente como recolectores de basura). Pero este no es un trabajo adecuado para pro- 
gramadores noveles. 


13.3.3. Sobrecarga de los operadores new y delete 

Cuando se ejecuta una expresion con new, ocurren dos cosas. Primero se asigna 
la memoria al ejecutar el codigo del operator new () y despues se realiza la lla¬ 
mada al constructor. En el caso de una expresion con delete, se llama primero al 
destructor y despues se libera la memoria con el operador operator delete (). 
Las llamadas al constructor y destructor no estan bajo el control del programador, 
pero se pueden cambiar las funciones opertator new() y operatator delet¬ 
ed. 

El sistema de asignacion de memoria usado por new y delete es un sistema de 
proposito general. En situaciones especiales, puede que no funcione como se requie- 
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re. Frecuentemente la razon para cambiar el asignador es la eficiencia; puede que 
se necesite crear y destruir tantos objetos de la misma clase que lo haga ineficaz en 
terminos de velocidad: un cuello de botella. En C++ es posible sobrecargar new y d- 
elete para implementar un esquema particular mas adecuado que permita manejar 
situaciones como esta. 

Otra cuestion es la fragmentacion del montlculo. Cuando los objetos tienen ta- 
manos diferentes es posible llegar a dividir de tal modo el area de memoria libre que 
se vuelva inutil. Es decir, el espacio puede estar disponible, pero debido al nivel de 
fragmentacion alcanzado, no exista ningun bloque del tamano requerido. Es posible 
asegurarse de que esto no llegue a ocurrir mediante la creation de un asignador para 
una clase espedfica. 

En los sistemas de tiempo real y en los sistemas integrados, suele ser necesario 
que los programas funcionen por largo tiempo con recursos muy limitados. Tales 
sistemas pueden incluso requerir que cada asignacion tome siempre la misma canti- 
dad de tiempo, y que no este permitida la fragmentacion ni el agotamiento en el area 
dinamica. La solution a este problema consiste en utilizar un asignador «personali- 
zado»; de otro modo, los programadores evitarian usar new y delete es estos casos 
y desperdiciarian un recurso muy valioso de C++. 

A la hora de sobrecargar operator new () y operator delete () es impor- 
tante tener en cuenta que lo unico que se esta cambiando es la forma en que se realiza 
la asignacion del espacio. El compilador llamara a la nueva version de new en lugar 
de al original, para asignar espacio, llamando despues al constructor que actuara so- 
bre el. Asi que, aunque el compilador convierte una expresion new en codigo para 
asignar el espacio y para llamar al constructor, todo lo que se puede cambiar al sobre¬ 
cargar new es la parte correspondiente a la asignacion. delete tiene una limitation 
similar. 

Cuando se sobrecarga operator new (), se esta reemplazando tambien el mo¬ 
do de tratar los posibles fallos en la asignacion de la memoria. Se debe decidir que 
acciones va a realizar en tal caso: devolver cero, un bucle de reintento con llamada 
al new-handier , o lo que es mas frecuente, disparar una exception bad_alloc (tema que 
se trata en el Volumen 2). 

La sobrecarga de new y delete es como la de cualquier otro operador. Existe la 
posibilidad de elegir entre sobrecarga global y sobrecarga para una clase determina- 
da. 

Sobrecarga global de new y delete 

Este es el modo mas drastico de abordar el asunto, resulta util cuando el compor- 
tamiento de new y delete no es satisfactorio para la mayor parte del sistema. Al 
sobrecargar la version global, quedan inaccesibles las originales, y ya no es posible 
llamarlas desde dentro de las funciones sobrecargadas. 

El new sobrecargado debe tomar un argumento del tipo size_t (el estandar de C) 
para tamanos. Este argumento es generado y pasado por el compilador, y se refiere al 
tamano del objeto para el que ahora tenemos la responsabilidad de la asignacion de 
memoria. Debe devolver un puntero a un bloque de ese tamano, (o mayor, si hubiera 
motivos para hacerlo asi), o cero en el caso de no se encontrara un bloque adecuado. 
Si eso sucede, no se producira la llamada al constructor. Por supuesto, hay que hacer 
algo mas informativo que solo devolver cero, por ejemplo llamar al «new-handler» 
o disparar una exception, para indicar que hubo un problema. 

El valor de retorno de operator new () es void*, no un puntero a un tipo parti¬ 
cular. Lo que hace es obtener un bloque de memoria, no un objeto definido, no hasta 
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que que sea llamado el constructor, un acto que el compilador garantiza y que esta 
fuera del control de este operador. 

El operador operator delete () toma como argumento un puntero void*' a un 
bloque obtenido con el operator new (). Es un void’ 1 ' ya que el delete obtiene 
el puntero solo despues de que haya sido llamado el destructor, lo que efectivamente 
elimina su caracter de objeto convirtiendolo en un simple bloque de memoria. El tipo 
de retorno para delete es void. 

A continuacion se expone un ejemplo del modo de sobrecargar globalmente new 

y delete: 

//: C13:GlobalOperatorNew.cpp 
// Overload global new/delete 

#include <cstdio> 

#include <cstdlib> 
using namespace std; 

void* operator new (size_t sz) { 

printf("operator new: %d BytesXn", sz); 

void* m = raalloc(sz); 

if(!m) puts ("out of memory"); 

return m; 

} 


void operator delete(void* m) { 

puts("operator delete"); 
free(m); 

} 


class S { 

int i[100]; 

public: 

S() { puts("S::S()"); } 

~S () { puts("S::~S() " ) ; } 

} ; 


int main () { 

puts ("creating & destroying an int"); 

int* p = new int (47); 
delete p; 

puts("creating & destroying an s"); 

S* s = new S; 

delete s; 

puts("creating & destroying S[3]"); 

S* sa = new S[3]; 

delete []sa; 

} ///:- 


Aqui puede verse la forma general de sobrecarga de operadores new y delete. 
Estos operadores sustitutivos usan las funciones malloc () y free () de la biblio- 
teca estandar de C, que es probablemente lo que ocurre en los operadores originales. 
Imprimen tambien mensajes sobre lo que estan haciendo. Notese que no se han usa- 
do iostreams sino printf () y puts (). Esto se hace debido a que los objetos 
iostream como los globales cin, cout y cerr llaman a new para obtener memoria 
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’. Usar print f () evita el fatal bloqueo, ya que no hace llamadas a new. 

En main (), se crean algunos objetos de tipos basicos para demostrar que tam- 
bien en estos casos se llama a los operadores new y delete sobrecargados. Poste- 
riormente, se crean un objeto simple y un vector, ambos de tipo S. En el caso del 
vector se puede ver, por el mimero de bytes pedidos, que se solicita algo de memoria 
extra para incluir informacion sobre el numero de objetos que tendra. En todos los 
casos se efectua la llamada a las versiones globales sobrecargadas de new y delete. 

Sobrecarga de new y delete especffica para una clase 

Aunque no es necesario poner el modificador static, cuando se sobrecarga n- 
ew y delete para una clase se estan creando metodos estaticos (metodos de clase). 
La sintaxis es la misma que para cualquier otro operador. Cuando el compilador 
encuentra una expresion new para crear un objeto de una clase, elige, si existe, un 
metodo de la clase llamado operator new () en lugar del new global. Para el resto 
de tipos o clases se usan los operadores globales (a menos que tengan definidos los 
suyos propios). 

En el siguiente ejemplo se usa un primitivo sistema de asignacion de almacena- 
miento para la clase Framis. Se reserva un bloque de memoria en el area de datos 
estatica FIXME , y se usa esa memoria para asignar alojamiento para los objetos de 
tipo Framis. Para determinar que bloques se han asignado, se usa un sencillo vector 
de bytes, un byte por bloque. 

//: C13 :Framis.cpp 
// Local overloaded new & delete 

#include <cstddef> // Size_t 
#include <fstream> 

#include <iostream> 

#include <new> 
using namespace std; 
ofstream out("Framis.out"); 

class Framis { 

enum { s z = 10 }; 

char c[sz]; // To take up space, not used 

static unsigned char pool[]; 
static bool alloc_map[]; 
public: 

enum { psize = 100 }; // frami allowed 

Framis() { out << "Framis()\n"; } 

-Framis() { out << "-Framis() ... } 

void* operator new(size_t) throw(bad_alloc); 

void operator delete(void*); 

} ; 

unsigned char Framis::pool[psize * sizeof(Framis)]; 
bool Framis::alloc_map[psize] = {false}; 

// Size is ignored — assume a Framis object 

void* 

Framis::operator new(size_t) throw(bad_alloc) { 
for(int i = 0; i < psize; i++) 
if(!alloc_map[i]) { 

out << "using block " << i << " ... "; 

alloc_map[i] = true; // Mark it used 

3 Provocaria una serie continua de llamadas a new hasta agotar la pila y abortarfa el programa. 
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return pool + (i * sizeof (Framis)); 

} 

out << "out of memory" << endl; 
throw bad_alloc(); 


void Framis:: operator delete(void* m) { 
if(!m) return; // Check for null pointer 
// Assume it was created in the pool 
// Calculate which block number it is: 

unsigned long block = (unsigned long)m 
- (unsigned long) pool; 
block /= sizeof (Framis); 

out << "freeing block " << block << endl; 
// Mark it free: 
alloc_map[block] = false; 


int main () { 

Framis* f[Framis::psize] ; 

try { 

for(int i = 0; i < Framis::psize; i++) 
f[i] = new Framis; 
new Framis; // Out of memory 
} catch (bad_alloc) { 

cerr << "Out of memory!" << endl; 

} 

delete f[10]; 

f[10] = 0; 

// Use released memory: 

Framis* x = new Framis; 

delete x; 

for(int j = 0; j < Framis::psize; j++) 

delete f[j]; // Delete f[10] OK 
} ///:- 


El espado de almacenamiento para el monticulo Framis se crea sobre el bloque 
obtenido al declarar un vector de tamaho suficiente para contener psize objetos de 
clase Framis. Se ha declarado tambien una variable logica para cada uno de los p- 
size bloques en el vector. Todas estas variables logicas son inicializadas a false 
usando el truco consistente en inicializar el primer elemento para que el compilador 
lo haga automaticamente con los restantes iniciandolos a su valor por defecto, fal¬ 
se, en el caso de variables logicas. 

El operador new () local usa la misma sintaxis que el global. Lo unico que hace 
es buscar una position libre, es decir, un valor false en el mapa de localization a- 
lloc_map. Si la encuentra, cambia su valor a true para marcarla como ocupada, y 
devuelve la direction del bloque correspondiente. En caso de no encontrar ningun 
bloque libre, envla un mensaje al fichero de trazas y dispara una exception de tipo 
bad_alloc. 

Este es el primer ejemplo con exception que aparece en este libro. En el Volu- 
men 2 se vera una discusion detallada del tratamiento de excepciones, por lo que 
en este ejemplo se hace un uso muy simple del mismo. En el operador new hay 
dos expresiones relacionadas con el tratamiento de excepciones. Primero, a la lista 
de argumentos de funcion le sigue la expresion throw (bad_alloc) , esto informa 
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al compilador que la funcion puede disparar una excepcion del tipo indicado. En se- 
gundo lugar, si efectivamente se agota la memoria, la funcion alcanzara la sentencia 
throw bad_alloc () lanzando la excepcion. En el caso de que esto ocurra, la fun¬ 
cion deja de ejecutarse y se cede el control del programa a la rutina de tratamiento 
de excepcion que se ha definido en una clausula catch (bad_alloc). 

En main () se puede ver la clausula try-catch que es la otra parte del mecanismo. 
El codigo que puede lanzar la excepcion queda dentro del bloque try; en este caso, 
llamadas a new para objetos Framis. Justo a continuacion de dicho bloque sigue 
una o varias clausulas catch, especificando en cada una la excepcion a la que se 
destina. En este caso, catch (bad_alloc) indica que en ese bloque se trataran las 
excepciones de tipo bad_alloc. El codigo de este bloque solo se ejecutara si se dispara 
la excepcion, continuando la ejecucion del programa justo despues de la ultima del 
grupo de clausulas catch que existan. Aqui solo hay una, pero podria haber mas. 

En este ejemplo, el uso de iostream es correcto ya que el operator new ( ) 
global no ha sido modificado. 

El operator delete () asume que la direccion de Framis ha sido obtenida 
de nuestro almacen particular. Una asuncion justa, ya que cada vez que se crea un 
objeto Framis simple se llama al operator new ( ) local; pero cuando se crea un 
vector de tales objetos se llama al new global. Esto causaria problemas si el usuario 
llamara accidentalmente al operador delete sin usar la sintaxis para destruction de 
vectores. Podria ser que incluso estuviera tratando de borrar un puntero a un objeto 
de la pila. Si cree que estas cosas puedan suceder, conviene pensar en anadir una 
linea que asegurare que la direccion esta en el intervalo correcto (aqui se demuestra 
el potencial que tiene la sobrecarga de los operadores new y delete para la locali¬ 
zation de fugas de memoria). 

operador delete () calcula el bloque al que el puntero representa y despues 
pone a false la bandera correspondiente en el mapa de localization, para indicar 
que dicho bloque esta libre. 

En la funcion main () , se crean dinamicamente suficientes objetos Framis para 
agotar la memoria. Con esto se prueba el comportamiento del programa en este caso. 
A continuacion, se libera uno de los objetos y se crea otro para mostrar la reutiliza- 
cion del bloque recien liberado. 

Este esquema especifico de asignacion de memoria es probablemente mucho mas 
rapido que el esquema de proposito general que usan los operadores new y delete 
originales. Se debe advertir, no obstante, que este enfoque no es automaticamente 
utilizable cuando se usa herencia, un tema que vera en el Capitulo 14 (FIXME). 

Sobrecarga de new y delete para vectores 

Si se sobrecargan los operadores new y delete para una clase, esos operadores 
se llaman cada vez que se crea un objeto simple de esa clase. Sin embargo, al crear 
un vector de tales objetos se llama al operator new () global para obtener el es- 
pacio necesario para el vector, y al operator delete () global para liberarlo. Es 
posible controlar tambien la asignacion de memoria para vectores sobrecargando los 
metodos operator new [ ] y operator delete []; se trata de versiones especia- 
les para vectores. A continuacion se expone un ejemplo que muestra el uso de ambas 
versiones. 

//: C13:ArrayOperatorNew.cpp 
// Operator new for arrays 
#include <new> // Size_t definition 
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#include <fstream> 
using namespace std; 

ofstream trace("ArrayOperatorNew.out") ; 

class Widget { 

enum { s z = 10 }; 
int i [ s z]; 

public: 

Widget() { trace << } 

-Widget() { trace << } 

void* operator new(size_t sz) { 

trace << "Widget::new: " 

<< sz << " bytes" << endl; 

return : :new char[s z]; 

} 

void operator delete(void* p) { 

trace << "Widget::delete" << endl; 

::delete []p; 

} 

void* operator new[] (size_t sz) { 
trace << "Widget::new[]: " 

<< sz << " bytes" << endl; 

return ::new char[s z]; 

} 

void operator delete [] (void* p) { 

trace << "Widget::delete[]" << endl; 

::delete []p; 



int main () { 

trace << "new Widget" << endl; 

Widget* w = new Widget; 

trace << "\ndelete Widget" << endl; 

delete w; 

trace << "\nnew Widget[25]" << endl; 

Widget* wa = new Widget[25]; 

trace << "\ndelete []Widget" << endl; 

delete []wa; 

} ///:- 


Si exceptuamos la informacion de rastreo que se anade aqui, las llamadas a las 
versiones globales de new y delete causan el mismo efecto que si estos operado- 
res no se hubieran sobrecargado. Como se ha visto anteriormente, es posible usar 
cualquier esquema conveniente de asignacion de memoria en estos operadores mo- 
dificados. 

Se puede observar que la sintaxis de new y delete para vectores es la misma 
que la usada para objetos simples anadiendoles el operador subindice [ ]. En ambos 
casos se le pasa a new como argumento el tamano del bloque de memoria solicitado. 
A la version para vectores se le pasa el tamano necesario para albergar todos sus 
componentes. Conviene tener en cuenta que lo unico que se requiere del operator 
new () es que devuelva un puntero a un bloque de memoria suficientemente grande. 
Aunque es posible inicializar el bloque referido, eso es trabajo del constructor, que 
se llamara automaticamente por el compilador. 
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El constructor y el destructor simplemente imprimen mensajes para que pueda 
verse que han sido llamados. A continuacion se muestran dichos mensajes: 


new Widget 

Widget::new: 40 bytes 
* 

delete Widget 
~Widget::delete 
new Widget[25] 

Widget::new: 1004 bytes 
************************* 
delete []Widget 

--Widget: : delete [ ] 


La creacion de un unico objeto Widget requiere 40 bytes, tal y como se podria 
esperar para una maquina que usa 32 bits para un int. Se invoca al operator ne- 
w () y luego al constructor, que se indica con la impresion del caracter «*». De forma 
complementaria, la llamada a delete provoca primero la invocacion del destructor 
y solo despues, la de operator delete (). 

Cuando lo que se crea es un vector de objetos Widget, se observa el uso de la ver¬ 
sion de operator new () para vectores, de acuerdo con lo dicho anteriormente. Se 
observa que el tamano del bloque solicitado en este caso es cuatro bytes mayor que el 
esperado. Es en estos cuatro bytes extra donde el compilador guarda la informacion 
sobre el tamano del vector. De ese modo, la expresion 

delete []Widget; 


informa al compilador que se trata de un vector, con lo cual, generara el codi- 
go para extraer la informacion que indica el numero de objetos y para llamar otras 
tantas veces al destructor. Observese que aunque se llame solo una vez a operator 
new() yoperator deleted para el vector, se llama al constructor y al destructor 
una vez para cada uno de los objetos del vector. 

Llamadas al constructor 

Considerando que 

MyType* f = new MyType; 

llama a new para obtener un bloque del tamano de MyType invocando despues 
a su constructor, ^que pasaria si la asignacion de memoria falla en new?. En tal caso, 
no habra llamada al constructor al que se le tendria quepasar un puntero this nulo, 
para un objeto que no se ha creado . He aqui un ejemplo que lo demuestra: 

//: C13:NoMemory.cpp 

// Constructor isn't called if new fails 
#include <iostream> 

#include <new> // bad_alloc definition 

using namespace std; 

class NoMemory { 

public: 

NoMemory() { 

cout << "NoMemory::NoMemory()" << endl; 

} 

void* operator new(size_t sz) throw (bad_alloc){ 
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cout << "NoMeraory::operator new" << endl; 
throw bad_alloc(); // "Out of memory" 


} ; 


int main () { 

NoMemory* nm = 0; 

try { 

nm = new NoMemory; 

} catch (bad_alloc) { 

cerr << "Out of memory exception" << endl; 

} 

cout << "nm = " << nm << endl; 

} ///:- 


Cuando se ejecuta, el programa imprime los mensajes del operator new () y 
del manejador de excepcion, pero no el del constructor. Como new nunca retorna, no 
se llama al constructor y por tanto no se imprime su mensaje. 

Para asegurar que no se usa indebidamente, Es importante inicializar nm a cero, 
debido a que new no se completa. El codigo de manejo de excepciones debe hacer 
algo mas que imprimir un mensaje y continuar como si el objeto hubiera sido creado 
con exito. Idealmente, deberia hacer algo que permitiera al programa recuperarse 
del fallo, o al menos, provocar la salida despues de registrar un error. 

En las primeras versiones de C++, el comportamiento estandar consistia en hacer 
que new retornara un puntero nulo si la asignacion de memoria fallaba. Esto podia 
impedir que se llamara al constructor. Si se intenta hacer esto con un compilador que 
sea conforme al estandar actual, le informara de que en lugar de devolver un valor 
nulo, debe disparar una excepcion de tipo bad_alloc. 

Operadores new y delete de [FIXME emplazamiento (situacion)] 

He aqui otros dos usos, menos comunes, para la sobrecarga de operador new- 

(): 


1. Puede ocurrir que necesite emplazar un objeto en un lugar especifico de la 
memoria. Esto puede ser importante en programas en los que algunos de los 
objetos se refieren o son sinonimos de componentes hardware mapeados sobre 
una zona de la memoria. 

2. Si se quiere permitir la eleccion entre varios asignadores de memoria (alloca¬ 
tors) en la llama da a new. 


Ambas situaciones se resuelven mediante el mismo mecanismo: la funcion op¬ 
erator new () puede tomar mas de un argumento. Como se ha visto, el primer 
argumento de new es siempre el tamano del objeto, calculado en secreto y pasado 
por el compilador. El resto de argumentos puede ser de cualquier otro tipo que se 
necesite: la direccion en la que queremos emplazar el objeto, una referenda a una 
funcion de asignacion de memoria, o cualquiera otra cosa que se considere conve- 
niente. 

Al principio puede parecer curioso el modo en que se pasan los argumentos extra 
al operator new (). Despues de la palabra clave new y antes del nombre de clase 
del objeto que se pretende crear, se pone la lista de argumentos, sin contar con el 
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correspondiente al size_t del objeto, que le pasa el compilador. Por ejemplo, la 
expresion: 

X* xp = new(a) X; 


pasara a como segundo argumento al operador operator new (). Por supues- 
to, solo funcionara si ha sido declarado el operator new () adecuado. 

He aqui un ejemplo demostrativo de como se usa esto para colocar un objeto en 
una posicion particular: 

//: C13:PlacementOperatorNew.cpp 
// Placement with operator new() 

#include <cstddef> // Size_t 
#include <iostream> 

using namespace std; 

class X { 
int i; 
public: 

X (int ii = 0) : i(ii) { 

cout << "this = " << this << endl; 

} 

~X() { 

cout << "X::~X(): " << this << endl; 

} 

void* operator new(size_t, void* loc) { 
return loc; 


} ; 


int main () { 

int 1 [ 10 ] ; 

cout << "1 = " << 1 << endl; 

X* xp = new(l) X(47); // X at location 1 
xp->X::~X(); // Explicit destructor call 

// ONLY use with placement! 

} ///:- 


Observe que lo unico que hace el operador new es retornar el puntero que se pasa. 
Por tanto, es posible especificar la direccion en la que se quiere construir el objeto. 

Aunque este ejemplo muestra solo un argumento adicional, nada impide anadir 
otros, si se considera conveniente para sus propositos. 

Al tratar de destruir estos objetos surge un problema. Solo hay una version del 
operador delete, de modo que no hay forma de decir: "Usa mi funcion de liberacion 
de memoria para este objeto”. Se requiere llamar al destructor, pero sin utilizar el 
mecanismo de memoria dinamica, ya que el objeto no esta alojado en el monticulo. 

La solucion tiene una sintaxis muy especial. Se debe llamar explicitamente al 
destructor, tal como se muestra: 


xp->X::~X(); //Llamada iexplcita al destructor 
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Hay que hacer una llamada de atencion al respecto. Algunas personas ven esto 
como un modo de destruir objetos en algun momento anterior al determinado por las 
reglas de ambito, en lugar de ajustar el ambito, o mas correctamente, en lugar de usar 
asignacion dinamica como medio de determinar la duration del objeto en tiempo de 
ejecucion. Esto es un error, que puede provocar problemas si se trata de destruir de 
esta manera un objeto ordinario creado en la pila, ya que el destructor sera llamado 
de nuevo cuando se produzca la salida del ambito correspondiente. Si se llama de 
esta forma directa al destructor de un objeto creado dinamicamente, se llevara a cabo 
la destruction, pero no la liberation del bloque de memoria, lo que probablemente 
no es lo que se desea. La unica razon para este tipo de llamada explicita al destructor 
es permitir este uso especial del operador new, para emplazamiento en memoria. 

Existe tambien una forma de operador delete de emplazamiento que solo es 
llamada en caso de que el constructor dispare una exception, con lo que la memoria 
se libera automaticamente durante la exception. El operador delete de emplaza¬ 
miento usa una lista de argumentos que se corresponde con la del operador new de 
emplazamiento que fue llamado previamente a que el constructor lanzase la excep¬ 
tion. Este asunto se tratara en el Volumen 2, en un capitulo dedicado al tratamiento 
de excepciones. 


13.4. Resumen 

La creation de objetos en la pila es eficaz y conveniente, pero para resolver el 
problema general de programacion es necesario poder crear y destruir objetos en 
cualquier momento en tiempo de ejecucion, en particular, para que pueda responder 
a la information externa al programa. Aunque C ofrece funciones de asignacion di¬ 
namica, estas no proporcionan la facilidad de uso ni la construction garantizada de 
objetos que se necesita en C++. Al llevar al nucleo mismo del lenguaje gracias al uso 
de los operadores new y delete, la creation dinamica de objetos se hace tan facil 
como la creation de objetos en la pila, anadiendo ademas una gran flexibilidad. Se 
puede modificar el comportamiento de new y delete si no se ajusta a los requeri- 
mientos, particularmente para mejorar la eficiencia, y tambien es posible definir su 
comportamiento en caso de agotarse la memoria libre. 


13.5. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Crear una clase Counted que contenga un int id yun static int coun- 
t. El constructor por defecto debe empezar con Counted () : id (count++) {. 
Tambien debera mostrar mensajes con su id, ademas de alguno que muestre 
que se esta creando. El destructor debe mostrar que esta siendo destruido y su 
id. Probar su funcionamiento. 

2. Compruebe que new y delete llaman siempre a constructores y destructores, 
creando mediante el uso de new un objeto de la clase Counted del ejercicio 1, 
y destruyendolo despues con delete. Cree y destruya un vector de Counted 
en el monticulo. 

3. Cree un objeto de la clase PStash, y llenelo de los objetos del ejercicio 1. Ob¬ 
serve lo que sucede cuando el objeto PStash sale de su ambito y es llamado 
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su destructor. 

4. Cree un vector de Counted* y carguelo con punteros a objetos Counted. Re- 
corra el vector llamando imprimiendo cada objeto, repita este paso y elimmelos 
uno a uno. 

5. Repita el ejercicio 4 anadiendo una funcion miembro f () de Counted que 
muestre un mensaje. Recorra el vector llamando a f () para cada objeto del 
vector. 

6. Repita el ejercicio 5 usando un objeto PStash. 

7. Repita el ejercicio 5 usando Stack4 . h del capitulo 9. 

8. Cree mediante asignacion dinamica un vector de objetos de clase Counted. 
Llame a delete con el puntero resultante como argumento, sin usar el opera- 
dor subindice []. Explique el resultado. 

9. Cree un objeto de clase Counted mediante new, convierta el puntero resultante 
a void* y luego borrelo. Explique el resultado. 

10. Compile y ejecute el programa NewHandler. cpp en su ordenador. A partir 
del numero resultante, calcule la cantidad de memoria libre disponible para su 
programa. 

11. Cree una clase y defina en ella operadores de sobrecarga para new y del¬ 
ete, para objetos simples y para vectores de objetos. Demuestre que ambas 
versiones funcionan. 

12. Disene un test que le permita evaluar de forma aproximada la mejora en velo- 
cidad obtenida en Framis . cpp con el uso de las versiones adaptadas de new 
y delete, respecto de la obtenida con las globales . 

13. Modifique NoMemory . cpp para que contenga un vector de enteros y realmen- 
te obtenga memoria en lugar de disparar bad_alloc. Establezca un bucle w- 
hile en el cuerpo de main () similar al que existe en NewHandler. cpp para 
agotar la memoria. Observe lo que sucede en el caso de que su operador n- 
ew no compruebe el exito de la asignacion de memoria. Anada despues esa 
comprobacion a su operador new y la llamada a throw bad_alloc. 

14. Cree una clase y defina un operador new de emplazamiento, con un string co¬ 
mo segundo argumento. Defina un vector de string, en el que se almacenara 
este segundo argumento a cada llamada a new. El operador new de emplaza¬ 
miento asignara bloques de manera normal. En main (), haga llamadas a este 
operador new pasandole como argumentos cadenas de caracteres que descri- 

ban las llamadas. Para ello, puede hacer uso de las macros_FILE_y_L- 

INE_del preprocesador. 

15. Modifique ArrayOperatorNew. cpp definiendo un vector estatico de Wid¬ 
get’ 1 ' que anada la direction de cada uno de los objetos Widget asignados con 
new, y la retire cuando sea liberada mediante delete. Puede que necesite bus- 
car information sebre vectores en la documentation de la biblioteca estandar 
de C++, o en el segundo volumen de este libro que esta disponible en la web 
del autor. Cree una segunda clase a la que llamara MemoryChecker, que con¬ 
tenga un destructor que muestre el numero de punteros a Widget en su vector. 
Disene un programa con una unica instancia global de MemoryChecker, y en 
main (), cree y destruya dinamicamente varios objetos y vectores de objetos 
Widget. Observe que MemoryCheck revela fugas de memoria. 
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14: Herencia y Composicion 

Una de las caractensticas mas importantes acerca de C++ es la re- 
utilizacion de codigo. Pero para ser revolucionario, necesita ser ca- 
paz de hacer algo mas que copiar codigo y modificarlo. 

Este es un enfoque de C y no fue demasiado bien. Como en la mayoria de los ca- 
sos en C++, la solucion gira alrededor de la clase. Se reutiliza codigo creando nuevas 
clases, pero en vez de crearlas desde la nada, utilizara clases existentes que alguien 
ha realizado y comprobado que funcionan correctamente. 

La clave consiste en utilizar estas clases sin modificarlas. En este capitulo, apren- 
dera los dos modos de hacerlo. El primero es bastante directo: simplemente cree 
objetos de la clase existente dentro de la nueva clase. A esto se le llama composicion 
porque la nueva clase esta compuesta por objetos de clases ya existentes. 

La segunda forma es mucho mas sutil. Crear la nueva clase como un tipo de una 
clase existente. Literalmente se toma la forma de la clase existente y se anade codigo, 
pero sin modificar la clase ya existente. A este hecho magico se le llama herencia, 
y la mayoria del trabajo es realizado por el compilador. La herencia es uno de los 
pilares de la programacion orientada a objetos y tiene extensiones adicionales que 
seran exploradas en el capitulo 15. 

Esto es, resulta que gran parte de la sintaxis y el comportamiento son similares 
tanto en la composicion como en la herencia (lo cual tiene sentido; ambas son dos 
formas de crear nuevos tipos utilizando tipos ya existentes). En este capitulo, apren- 
dera acerca de los mecanismos para la reutilizacion de codigo. 

14.1. Sintaxis de la composicion 

Realmente, ha utilizado la composicion a lo largo de la creacion de una clase. 
Ha estado construyendo clases principalmente con tipos predefinidos (y en ocasio- 
nes cadenas). Por esto, resulta facil usar la composicion con tipos definidos por el 
usuario. 

Considere la siguiente clase: 

// : C14:Useful.h 
// A class to reuse 

#ifndef USEFUL_H 
#define USEFUL_H 


class X { 
int i; 
public: 
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X() { i = 0; } 

void set (int ii) { i = ii; } 
int read() const { return i; } 

int permute() { return i = i * 47; } 

} ; 

#endif // USEFUL_H ///:- 


En esta clase los miembros son privados, y entonces, es completamente seguro 
declarar un objeto del tipo X publico en la nueva clase, y por ello, permitir una inter- 
faz directa: 

//: C14:Composition.cpp 
// Reuse code with composition 

#include "Useful.h" 

class Y { 
int i; 
public: 

X x; // Embedded object 

Y() { i = 0; } 

void f (int ii) { i = ii; } 

int g() const { return i; } 

} ; 


int main () { 

Y y; 

y.f(47) ; 

y.x.set(37); // Access the embedded object 
} ///:~ 


Para acceder a las funciones miembro alojadas en el objeto (referido como subob- 
jeto) simplemente requiere otra seleccion del miembro. 

Es habitual hacer privado el objeto alojado, y por ello, formar parte de la capa 
de implementation (lo que significa que es posible cambiar la implementation si se 
desea). La interfaz de funciones de la nueva clase implica el uso del objeto alojado, 
pero no necesariamente imita a la interfaz del objeto. 

//: C14:Composition2.cpp 
// Private embedded objects 

#include "Useful.h" 

class Y { 
int i; 

X x; // Embedded object 

public: 

Y() { i = 0; } 

void f (int ii) { i = ii; x.set(ii); } 

int g() const { return i * x.readO; } 
void permute() { x.permute(); } 

} ; 


int main () { 

Y y; 

y.f (47) ; 
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y.permute() ; 

} ///:- 


Aqui, la funcion permute() se ha anadido a la interfaz de la clase, pero el resto 
funciones de X son utilizadas dentro de los miembros de Y. 


14.2. Sintaxis de la herencia 

La sintaxis en la composicion es bastante obvia, en cambio en la herencia, la sin¬ 
taxis es nueva y diferente. 

Cuando hereda, realmente se expresa "Esta nueva clase es como esta otra vieja 
clase". Se comienza el codigo proporcionando el nombre de la clase, como se reali- 
za normalmente, pero antes de abrir la Have del cuerpo de la clase, se colocan dos 
puntos y el nombre de la clase base (o de las clases bases, separadas por comas, pa¬ 
ra herencia multiple). Una vez realizado, automaticamente se consiguen todos los 
miembros y las funciones de la clase base. Ejemplo: 

//: C14:Inheritance.cpp 
// Simple inheritance 

#include "Useful.h" 

#include <iostream> 

using namespace std; 

class Y : public X { 

int i; // Different from X's i 

public: 

Y 0 { i = 0; } 
int change() { 

i = permute(); // Different name call 

return i; 

} 

void set (int ii) { 
i = ii; 

X::set(ii); // Same-name function call 


} ; 


int main () { 

cout << "sizeof(X) = " << sizeof (X) << endl; 
cout << "sizeof (Y) = " 

<< sizeof (Y) << endl; 

Y D; 

D .change (); 

//X function interface comes through: 

D .read (); 

D .permute(); 

// Redefined functions hide base versions: 

D .set (12) ; 

} | / / : ~ 


Como se puede observar, Y hereda de X, que significa que Y contendra todos los 
miembros de X y todas las funciones de X. De hecho, Y contiene un subobjeto X como 
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si se hubiese creado un objeto X dentro de la clase Y en vez de heredar de X. Tanto 
los miembros objetos y la clase base son conocidos como subobjetos. 

Todos los elementos privados de X continuan siendo privados en Y; esto es, aun- 
que Y hereda de X no significa que Y pueda romper el mecanismo de protection. Los 
elementos privados de X continuan existiendo, ocupando su espacio - solo que no se 
puede acceder a ellos directamente. 

En main() observamos que los datos de Y estan combinados con los datos de X 
porque sizeof(Y) es el doble de grande que el sizeof(X). 

Observara que la clase base es precedida por public. Durante la herencia, por de- 
fecto, todo es privado. Si la clase base no estuviese precedida por public, significaria 
que todos los miembros publicos de la clase base serian privados en la clase deriva- 
da. Esto, en la mayoria de ocasiones no es lo deseado [51]; el resultado que se desea 
es mantener todos los miembros publicos de la clase base en la clase derivada. Para 
hacer esto, se usa la palabra clave public durante la herencia. 

En change(), se utiliza a la funcion de la clase base permute(). La clase derivada 
tiene acceso directo a todas las funciones publicas de la clase base. 

La funcion set() en la clase derivada redefine la funcion set() de la clase base. Esto 
es, si llama a las funciones readQ y permute() de un objeto Y, conseguira las versiones 
de la clase base (esto es lo que esta ocurriendo dentro de mainQ). Pero si llamamos 
a set() en un objeto Y, conseguiremos la version redefinida. Esto significa que si no 
deseamos un comportamiento de una funcion durante la herencia, se puede cambiar. 
(Tambien se pueden ahadir funciones completamente nuevas como change().) 

Sin embargo, cuando redefinimos una funcion, puede ser que desee llamar a la 
version de la clase base. Si, dentro de set(), simplemente llama a set(), conseguiremos 
una version local de la funcion - una funcion recursiva. Para llamar a la version de 
la clase base, se debe explicitamente utilizar el nombre de la clase base y el operador 
de resolution de alcance. 


14.3. Lista de inicializadores de un constructor 

Hemos visto lo importante que es en C++ garantizar una correcta initialization, 
y esto no va a cambiar en la composicion ni en la herencia. Cuando se crea un objeto, 
el compilador garantiza la ejecucion todos los constructores para cada uno de los 
subobjetos. Hasta ahora, en los ejemplos, todos los subobjetos tienen un constructor 
por defecto, que es ejecutado por el compilador automaticamente. Pero que ocurre si 
uno de nuestros subobjetos no tiene constructores por defecto, o si queremos cambiar 
los parametros por defecto de un constructor. Esto supone un problema, porque el 
constructor de la nueva clase no tiene permiso para acceder a los miembros privados 
del subobjeto y por ello, no puede inicializarlos directamente. 

La solution es simple: ejecutar el constructor del subobjeto. C++ proporciona una 
sintaxis especial para ello, la lista de inicializadores de un constructor. La forma de 
la lista de inicializadores de un constructor demuestra como actua como la heren¬ 
cia. Con la herencia, las clases bases son colocadas despues de dos puntos y justo 
despues, puede abrir la Have para empezar con el cuerpo de la clase. En la lista de 
inicializadores de un constructor, se coloca las llamadas a los constructores de los 
subobjetos, despues los argumentos del constructor y los dos puntos, pero todo esto, 
antes de abrir el brazo del cuerpo de la funcion. En una clase MyType, que hereda 
de Bar, seria de la siguiente manera: 
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MyType::MyType(int i) : Bar(i) { // ... 


si el constructor de Bar tuviera un solo parametro del tipo int. 


14.3.1. Inicializacion de objetos miembros 

La inicializacion de objetos miembros de una clase utiliza la misma sintaxis cuan- 
do se usa la composicion. Para la composicion, se proporcionan los nombres de los 
objetos en lugar de los nombres de las clases. Si se tiene mas de una llamada al cons¬ 
tructor en la lista de inicializadores, las llamadas se separan con comas: 

MyType2::MyType2(int i) : Bar(i), m(i+l) { // ... 


Esta seria la forma de un constructor de la clase MyType2, la cual hereda de Bar 
y contiene un miembro objeto llamado m. Fijese que mientras podemos ver el tipo 
de la clase base en la lista de inicializadores del constructor, solo podemos ver el 
miembro identificador objeto. 


14.3.2. Tipos predefinidos en la lista de inicializadores 

La lista de inicializadores del constructor permite invocar explicitamente a los 
constructores de los objetos miembros. De hecho, no existe otra forma de llamar a 
esos constructores. La idea es que los constructores son llamados antes de la ejecu- 
cion del cuerpo del constructor de la nueva clase. De esta forma, cualquier llamada 
que hagamos a las funciones miembros de los subobjetos siempre seran objetos ini- 
cializados. No existe otra manera de acceder al cuerpo del constructor sin que ningun 
constructor llame a todos los miembros objetos y los objetos de la clase base, es mas, 
el compilador crea un constructor oculto por defecto. Esto es otra caracteristica de 
C++, que garantiza que ningun objeto (o parte de un objeto) puedan estar desde un 
principio sin que su constructor sea llamado. 

La idea de que todos los objetos miembros esten inicializados al inicio del cons¬ 
tructor es una buena ayuda para programar. Una vez en el inicio del constructor, 
puede asumir que todos los subobjetos estan correctamente inicializados y centrarse 
en las tareas que se desean realizar en el constructor. Sin embargo, existe un contra- 
tiempo: ^Que ocurre con los objetos predefinidos, aquellos que no tienen construc¬ 
tor? 

Para hacer una sintaxis solida, piense en los tipos predefinidos como si tuviesen 
un solo constructor, con un solo parametro: una variable del mismo tipo como el que 
esta inicializando. Esto es 

//: C14:PseudoConstructor.cpp 

class X { 
int i; 
float f; 
char c; 
char* s; 
public: 

X() : i (7), f(1.4), c('x'), s( "howdy" ) {} 

1 ; 


int main () { 
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X x; 

int i(100); // Applied to ordinary definition 

int* ip = new int (47); 

} ///:~ 


El proposito de esta "pseudo-llamadas a los constructores" es una simple asigna- 
cion. Es una tecnica recomendada y un buen estilo de programacion, que usted vera 
usar a menudo. 

ncluso es posible utilizar esta sintaxis cuando se crean variables de tipos predefi- 
nidos fuera de la clase: 

int i(100); 

int* ip = new int (47); 


De esta forma, los tipos predefinidos actuan, mas o menos, como los objetos. Sin 
embargo, recuerde que no son constructores reales. En particular, si usted no realiza 
una llamada explicita al constructor, no se ejecutara ninguna inicializacion. 


14.3.3. Combinacion de composicion y herencia 

Por supuesto, usted puede usar la composicion y la herencia a la vez. El siguiente 
ejemplo muestra la creacion de una clase mas compleja utilizando composicion y 
herencia. 

//: C14 :Combined.cpp 
// Inheritance & composition 

class A { 
int i; 
public: 

A (int ii) : i (ii) { } 

~A() {} 

void f() const {} 

} ; 


class B { 
int i; 
public: 

B (int ii) : i (ii) { } 
~B() {} 

void f() const {} 

1 ; 


class C : public B { 

A a; 

public: 

C(int ii) : B(ii), a(ii) {} 

~C() {} // Calls ~A() and ~B() 

void f() const { // Redefinition 

a.f 0 ; 

B : : f () ; 


}; 
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int main () { 

C c (47) ; 

} ///:- 


C hereda de B y tiene un objeto miembro ("esta compuesto de") del tipo A. Puede 
comparar que la lista de inicializadores contiene las llamadas al constructor de la 
clase base y las constructores de los objetos miembros. 

La funcion C::f() redefine B::f(), que era heredada, y tambien llama a la version de 
la clase base. Ademas, se llama a a.f(). Fijese que durante todo este tiempo estamos 
hablando acerca de la redefinicion de funciones durante la herencia; con un objeto 
miembro que solo se puede manipular su interfaz publica, no redefinirla. Ademas, 
al llamar a f() en un objeto de la clase C no podra llamar a a.f() si C::f() no ha sido 
definido, mientras que seria posible llamar a B::f(). 

Llamadas automaticas al destructor 

Aunque muy a menudo sea necesario realizar llamadas explicitas a los construc¬ 
tores en la inicializacion, nunca sera necesario realizar una llamada explicita a los 
destructores porque solo existe un destructor para cada clase y este no tiene parame- 
tros. Sin embargo, el compilador asegura que todos los destructores son llamados, 
esto significa que todos los destructores de la jerarquia, desde el destructor de la 
clase derivada y retrocediendo hasta la raiz, seran ejecutados. 

Es necesario destacar que los constructores y destructores son un poco inusuales 
en el modo en que llaman a su jerarquia, en una funcion miembro normal solo la 
funcion en si es llamada, ninguna version de la clase base. Si usted desea llamar a 
la version de la clase base de una funcion miembro normal, debera sobrecargarla y 
debera llamarla explicitamente. 


14.3.4. Orden de llamada de constructores y destructores 

Es importante conocer el orden de las llamadas de los constructores y destructo¬ 
res de un objeto con varios subobjetos. El siguiente ejemplo muestra como funciona: 

//: C14:Order.cpp 
// Constructor/destructor order 

#include <fstream> 
using namespace std; 
ofstream out("order.out"); 

#define CLASS (ID) class ID { \ 
public: \ 

ID (int) { out << #ID " constructor\n"; } \ 

~ ID () { out << # ID " destructor\n"; } \ 

) ; 

CLASS(Basel); 

CLASS(Member1); 

CLASS(Member2); 

CLASS(Member3); 

CLASS(Member4); 


class Derivedl : public Basel { 
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Member1 ml; 

Member2 m2; 

public: 

Derivedl (int) ; m2(l), ml(2), Basel(3) { 

out << "Derivedl constructor\n"; 

} 

-Derivedl() { 

out << "Derivedl destructor\n"; 


} ; 


class Derived2 : public Derivedl { 

Member3 m3; 

Member4 m4; 

public: 

Derived2() : m3(l), Derivedl(2), m4(3) { 

out << "Derived2 constructor\n"; 

} 

~Derived2() { 

out << "Derived2 destructor\n"; 

} 


int main() { 
Derived2 d2; 
} ///:- 


Primero, se crea un objeto ofstream para enviar la salida a un archivo. Entonces, 
para no teclear tanto y demostrar la tecnica de las macros que sera sustituida por 
otra mucho mas mejorada en el capitulo 16, se crea una para construir varias clases 
que utilizan herencia y composicion. Cada constructor y destructor escribe informa- 
cion en el archivo de salida. Fijense que los constructores no son constructores por 
defecto; cada uno tiene un parametro del tipo int. Y ademas, el argumento no tiene 
nombre; la unica razon de su existencia es forzar la llamada al constructor en la lista 
de inicializadores del constructor. (Eliminando el identificador evita que el compila- 
dor informe con mensajes de advertencia) 

La salida de este programa es 


Basel constructor 
Memberl constructor 
Member2 constructor 
Derivedl constructor 
Member3 constructor 
Member4 constructor 
Derived2 constructor 
Derived2 destructor 
Member4 destructor 
Member3 destructor 
Derivedl destructor 
Member2 destructor 
Memberl destructor 
Basel destructor 


omo puede observar, la construction empieza desde la raiz de la jerarquia de 
clases y en cada nivel, el constructor de la clase base se ejecuta primero, seguido por 
los constructores de los objetos miembro. Los destructores son llamados exactamente 
en el orden inverso que los constructores -esto es importante debido a los problemas 
de dependencias (en el constructor de la clase derivada o en el destructor, se debe 
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asumir que el subobjeto de la clase base esta todavla disponible para su uso, y ha 
sido construido - o no se ha destruido todavla). 

Tambien es interesante que el orden de las llamadas al constructor para los ob- 
jetos miembro no afecten para nada el orden de las llamadas en la lista de iniciali- 
zadores de un constructor. El orden es determinado por el orden en que los objetos 
miembros son declarados en la clase. Si usted pudiera cambiar el orden del construc¬ 
tor en la lista de inicializadores de un constructor, usted podrla tener dos secuencias 
diferentes de llamada en dos constructores diferentes, pero el destructor no sabrla 
como invertir el orden para llamarse correctamente y nos encontrarlamos con pro- 
blemas de dependencias. 


14.4. Ocultacion de nombres 

Si se ha heredado de una clase y se proporciona una nueva definicion para algu- 
na de sus funciones miembros, existen dos posibilidades. La primera es proporcionar 
los mismos argumentos y el mismo tipo de retorno en la definicion de la clase deriva- 
da como la clase base. Esto es conocido como redefinicion para funciones miembro 
ordinarias y sobrecarga, cuando la funcion miembro de la clase es una funcion virtual 
(las funciones virtuales son un caso normal y seran tratadas en detalle en el capitulo 
15). Pero <i,que ocurre cuando se modifican los argumentos de la funcion miembro o 
el tipo de retorno en una clase derivada? Aqui esta un ejemplo: 

//: C14:NameHiding.cpp 

// Hiding overloaded names during inheritance 

#include <iostream> 

#include <string> 
using namespace std; 

class Base { 
public: 

int f() const { 

cout << "Base::f()\n"; 

return 1; 

} 

int f(string) const { return 1; } 

void g() {} 

} ; 


class Derivedl : public Base { 
public: 

void g() const {} 

} ; 


class Derived2 : public Base { 
public: 

// Redefinition: 

int f() const { 

cout << "Derived2::f()\n"; 

return 2; 


} ; 


class Derived3 : public Base { 
public: 
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// Change return type: 

void f() const { cout << "Derived3::f()\n"; } 


class Derived4 : public Base { 
public: 

// Change argument list: 

int f(int) const { 

cout << "Derived4::f()\n"; 

return 4; 

} 


int main ( ) { 

string s("hello"); 

Derivedl dl; 
int x = dl. f () ; 
dl.f (s) ; 

Derived2 d2; 
x = d2.f () ; 

//! d2.f(s); // string version hidden 

Derived3 d3; 

//! x = d3.f(); // return int version hidden 
Derived4 d4; 

//! x = d4.f(); // f() version hidden 
x = d4.f(1); 

} ///:- 


En Base se observa una funcion sobrecargada f(), en Derivedl no se realiza nin- 
gun cambio a f() pero se redefine la funcion g(). En mainQ, se observa que ambas 
funciones f() estan disponibles en Derivedl. Sin embargo, Derived2 redefine una 
version sobrecargada de f() pero no la otra, y el resultado es que la segunda forma 
de sobrecarga no esta disponible. En Derived3, se ha cambiado el tipo de retorno 
y esconde ambas versiones de la clase base, y Derived4 muestra que al cambiar la 
lista de argumentos tambien se esconde las versiones de la clase base. En general, 
usted puede expresar cada vez que redefine una funcion sobrecargada de la clase 
base, que todas las otras versiones son automaticamente escondidas en la nueva cla¬ 
se. En el capitulo 15, vera como anadir la palabra reservada virtual que afecta un 
significativamente a la sobrecarga de una funcion. 

Si cambia la interfaz de la clase base modificando la signatura y/o el tipo de 
retorno de una funcion miembro desde la clase base, entonces esta utilizando la clase 
de una forma diferente en que la herencia esta pensado para realizar normalmente. 
Esto no quiere decir que lo que este haciendo sea incorrecto, esto es que el principal 
objetivo de la herencia es soportar el polimorfismo, y si usted cambia la signatura de 
la funcion o el tipo de retorno entonces realmente esta cambiando la interfaz de la 
clase base. Si esto es lo que esta intentando hacer entonces esta utilizando la herencia 
principalmente para la reutilizacion de codigo, no para mantener interfaces comunes 
en la clase base (que es un aspecto esencial del poliformismo). En general, cuando 
usa la herencia de esta forma significa que esta en una clase de proposito general y la 
especializacion para una necesidad particular - que generalmente, pero no siempre, 
se considera parte de la composicion. 

Por ejemplo, considere la clase Stack del capitulo 9. Uno de los problemas con 
esta clase es que se tenia que realizar que convertir cada vez que se conseguia un 
puntero desde el contenedor. Esto no es solo tedioso, tambien inseguro - se puede 
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convertir a cualquier cosa que desee. 

Un procedimiento que a primera vista parece mejor es especializar la clase gene¬ 
ral Stack utilizando la herencia. Aqui esta un ejemplo que utiliza la clase del capitulo 
9. 

//: C14:InheritStack.cpp 
// Specializing the Stack class 

#include "../C09/Stack4.h" 

#include "../require.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

class StringStack : public Stack { 
public: 

void push(string* str) { 

Stack::push(str) ; 

} 

string* peek() const { 

return (string*)Stack::peek(); 

} 

string* pop() { 

return (string*)Stack::pop (); 

} 

-StringStack () { 

string* top = pop (); 
while (top) { 
delete top; 
top = pop(); 

} 


} ; 


int main ( ) { 

ifstream in("InheritStack.cpp"); 
assure(in, "InheritStack.cpp") ; 
string line; 

StringStack textlines; 
while (getline(in, line)) 

textlines.push (new string(line) ) ; 
string* s; 

while((s = textlines.pop()) != 0) { // No cast! 

cout << *s << endl; 

delete s; 

} 

} ///:- 


Como todas las funciones miembros en Stack4.h son inline, no es necesario ser 
enlazadas. 

StringStack especializa Stack para que push() acepte solo punteros a String. An¬ 
tes, Stack acepta punteros a void, y as! el usuario no tenia que realizar una compro- 
bacion de tipos para asegurarse que el punteros fuesen insertados. Ademas, peekQ 
and pop() ahora retornan punteros a String en vez de punteros a void, entonces no 
es necesario realizar la conversion para utilizar el puntero. 
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orprendido jeste mecanismo de comprobacion de tipos seguro es gratuito, en 
push(), peek() y pop! A1 compilador se le proporciona information extra acerca de 
los tipos y este lo utiliza en tiempo de compilation, pero las funciones son inline y 
no es necesario ningun codigo extra. 

La ocultacion de nombres entra en accion en la funcion push() que tiene la sig¬ 
nature diferente: la lista de argumentos. Si se tuviesen dos versiones de push() en la 
misma clase, tendrian que ser sobrecargadas, pero en este caso la sobrecarga no es 
lo que deseamos porque todavia permitiria pasar cualquier tipo de puntero a push 
como void *. Afortunadamente, C++ esconde la version push (void *) en la clase base 
en favor de la nueva version que es definida en la clase derivada, de este modo, solo 
se permite utilizar la funcion push() con punteros a String en StringStack. 

Ahora podemos asegurar que se conoce exactamente el tipo de objeto que esta 
en el contenedor, el destructor funcionara correctamente y problema esta resuelto - 
o al menos, un parte del procedimiento. Si utiliza push() con un puntero a String en 
StringStack, entonces (segun el significado de StringStack) tambien se esta pasando 
el puntero a StringStack. Si utiliza pop(), no solo consigue puntero, sino que a la vez 
el propietario. Cualquier puntero que se haya dejado en StringStack sera borrado 
cuando el destructor sea invocado. Puesto que siempre son punteros a Strings y la 
declaration delete esta funcionando con punteros a String en vez de punteros a void, 
la destruction se realiza de forma adecuada y todo funciona correctamente. 

Esto es una desventaja: esta clase solo funciona con punteros de cadenas. Si se 
desea un Stack que funcione con cualquier variedad de objetos, se debe escribir una 
nueva version de la clase que funcione con ese nuevo tipo de objeto. Esto puede 
convertirse rapidamente en una tarea tediosa, pero finalmente es resulta utilizando 
plantillas como se vera en el capitulo 16. 

Existen consideraciones adicionales sobre este ejemplo: el cambio de la interfaz 
en Stack en el proceso de herencia. Si la interfaz es diferente, entonces StringStack 
no es realmente un Stack, y nunca sera posible usar de forma correcta un StringStack 
como Stack. Esto hace que el uso de la herencia sea cuestionable en este punto; si 
no se esta creando un StringStack del tipo Stack, entonces, porque hereda de el. Mas 
adelante, sen este mismo capitulo se mostrara una version mas adecuada. 


14.5. Funciones que no heredan automaticamente 

No todas las funciones son heredadas automaticamente desde la clase base a la 
clase derivada. Los constructores y destructores manejan la creation y la destruc¬ 
tion de un objeto y solo ellos saben que hacer con los aspectos de un objeto en sus 
clases particulares y por ello los constructores y destructores inferiores de la jerar- 
quia deben llamarlos. Asi, los constructores y destructores no se heredan y deben ser 
creados especificamente en cada clase derivada. 

Ademas, operator= tampoco se hereda porque realiza una accion parecida al 
constructor. Esto es, solo porque conoce como asignar todos los miembros de un 
objeto, la parte izquierda del = a la parte derecha del otro objeto, no significa que la 
asignacion tendra el mismo significado despues de la herencia. 

En la herencia, estas funciones son creadas por el compilador si no son creadas 
por usted. (Con constructores, no se pueden crear constructores para que el com¬ 
pilador cree el constructor por defecto y el constructor copia.) Esto fue brevemente 
descrito en el capitulo 6. Los constructores creados se usan en initialization de sus 
miembros y la creation del opera tor = usa la asignacion de los miembros. A conti¬ 
nuation, un ejemplo de las funciones que son creadas por el compilador. 
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//: C14:SynthesizedFunctions.cpp 

// Functions that are synthesized by the compiler 

#include <iostream> 

using namespace std; 

class GameBoard { 

public: 

GameBoard() { cout << "GameBoard()\n" ; } 

GameBoard(const GameBoardS) { 

cout << "GameBoard(const GameBoardS)\n"; 

} 

GameBoardS operator=(const GameBoardS) { 
cout << "GameBoard::operator=()\n"; 

return *this; 

) 

-GameBoard() { cout << "-GameBoard()\n"; } 

} ; 

class Game { 

GameBoard gb; // Composition 

public: 

// Default GameBoard constructor called: 

Game() { cout << "Game()\n"; } 

// You must explicitly call the GameBoard 
// copy-constructor or the default constructor 
// is automatically called instead: 

Game(const Games g) : gb(g.gb) { 
cout << "Game(const Games)\n"; 

} 

Game(int) { cout << "Game(int)\n"; } 

Games operator=(const Games g) { 

// You must explicitly call the GameBoard 
// assignment operator or no assignment at 
// all happens for gb! 
gb = g. gb ; 

cout << "Game::operator=()\n"; 

return *this; 

} 

class Other {}; // Nested class 
// Automatic type conversion: 

operator Other () const { 

cout << "Game::operator Other()\n"; 
return Other(); 

} 

-Game() { cout << "-Game()\n"; } 

} ; 

class Chess : public Game {}; 

void f(Game::Other) {} 

class Checkers : public Game { 
public: 

// Default base-class constructor called: 
Checkers () { cout << "Checkers ()\n"; } 

// You must explicitly call the base-class 
// copy constructor or the default constructor 


415 
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// will be automatically called instead: 
Checkers (const CheckersS c) : Game(c) { 
cout << "Checkers(const CheckersS c)\n"; 

} 

CheckersS operator=(const CheckersS c) { 

// You must explicitly call the base-class 
// version of operator=() or no base-class 
// assignment will happen: 

Game:: operator= (c); 

cout << "Checkers::operator=()\n" ; 

return *this; 



int main () { 

Chess dl; // Default constructor 
Chess d2(dl); // Copy-constructor 

//! Chess d3(l); // Error: no int constructor 
dl = d2; // Operator= synthesized 
f(dl); // Type-conversion IS inherited 

Game::Other go; 

//! dl = go; // Operator= not synthesized 
// for differing types 
Checkers cl, c2(cl); 
cl = c2; 

} ///:- 


Los constructores y el operator= de GameBoard y Game se describen por si solos 
y por ello distinguira cuando son utilizados por el compilador. Ademas, el operador 
Other() ejecuta una conversion automatica de tipo desde un objeto Game a un objeto 
de la clase anidada Other. La clase Chess simplemente hereda de Game y no crea 
ninguna funcion (solo para ver como responde el compilador) La funcion f() coge un 
objeto Other para comprobar la conversion automatica del tipo. 

En main(), el constructor creado por defecto y el constructor copia de la clase 
derivada Chess son ejecutados. Las versiones de Game de estos constructores son 
llamados como parte de la jerarquia de llamadas a los constructores. Aun cuando 
esto es parecido a la herencia, los nuevos constructores son realmente creados por 
el compilador. Como es de esperar, ningun constructor con argumentos es ejecutado 
automaticamente porque es demasiado trabajo para el compilador y no es capaz de 
intuirlo. 

El operator= es tambien es creado como una nueva funcion en Chess usando 
la asignacion (asi, la version de la clase base es ejecutada) porque esta funcion no 
fue explicitamente escrita en la nueva clase. Y, por supuesto el destructor es creado 
automaticamente por el compilador. 

El porque de todas estas reglas acerca de la reescritura de funciones en relacion a 
la creacion de un objeto pueden parecer un poco extranas en una primera impresion 
y como se heredan las conversiones automaticas de tipo. Pero todo esto tiene sentido 
- si existen suficiente piezas en Game para realizar un objeto Other, aquellas piezas 
estan todavia en cualquier objeto derivado de Game y el tipo de conversion es valido 
(aun cuando puede, si lo desea, redefinirlo). 

El operator= es creado automaticamente solo para asignar objeto del mismo tipo. 
Si desea asignar otro tipo, debera escribir el operator= usted mismo. 
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Si mira con detenimiento Game, observara que el constructor copia y la asigna¬ 
cion tienen llamadas explicitas a constructor copia del objeto miembro y al operador 
de asignacion. En la mayoria de ocasiones, debera hacer esto porque sino, en vez 
del constructor copia, sera llamado el constructor por defecto del objeto miembro, 
y en el caso del operador de asignacion, jninguna asignacion se hara en los objetos 
miembros! 

Por ultimo, fijese en Checkers, donde explicitamente se escribe un constructor por 
defecto, constructor copia y los operadores de asignacion. En el caso del constructor 
por defecto, el constructor por defecto de la clase base se llama automaticamente, 
y esto es lo normalmente que se desea hacer. Pero, aqui existe un punto importan- 
te, tan pronto que se decide escribir nuestro propio constructor copia y operador de 
asignacion, el compilador asume que usted sabe lo que esta haciendo y no ejecu- 
tara automaticamente las versiones de la clase base asi como las funciones creadas 
automaticamente. Si se quiere ejecutar las versiones de la clase base, debe llamarlas 
explicitamente. En el constructor copia de Checkers, esta llamada aparece en la lista 
de inicializacion del constructor: 

Checkers (const CheckersS c) : Game(c) { 

En el operador de asignacion de Checkers, la clase base se llama en la primera 
linea del cuerpo de la funcion: 

Game::operator=(c); 


Estas llamadas deben seguirse de forma canonica cuando usa cualquier clase de- 
rivada. 


14.5.1. Herencia y metodos estaticos 

Las funciones miembro estaticas funcionan igual que las funciones miembros no 
estaticas: 

1. Son heredadas en la clase derivada. 

2. Si redefine un miembro estatico, el resto de funciones sobrecargadas en la clase 
base son ocultas. 

3. Si cambia la signatura de una funcion en la clase base, todas las versiones con 
ese nombre de funcion en la clase base son ocultadas (esto es realmente una 
variacion del punto anterior). 

Sin embargo, las funciones miembro estaticas no pueden ser virtuales (este tema 
se cubrira detenidamente en el capitulo 15). 


14.5.2. Composicion vs. herencia 

La composicion y la herencia colocan subobjetos dentro de la clase. Ambos usan 
la lista de inicializacion del constructor para construir esos subobjetos. Pero se pre- 
guntara cual es la diferencia entre los dos, y cuando escoger una y no la otra. 

La composicion generalmente se usa cuando se quieren las caracteristicas de una 
clase existente dentro se su clase, pero no en su interfaz. Esto es, aloja un objeto para 
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implementar caracteristicas en su clase, pero el usuario de su clase ve el interfaz que 
se ha definido, en vez del interfaz de la clase original. Para hacer esto, se sigue el 
tipico patron de alojar objetos privados de clases existentes en su nueva clase. 

En ocasiones, sin embargo, tiene sentido permitir que el usuario de la clase ac- 
ceda a la composicion de su clase, esto es, hacer publicos los miembros objeto. Los 
miembros objeto usan su control de accesos, entonces es seguro y cuando el usuario 
conoce que esta formando un conjunto de piezas, hace que la interfaz sea mas facil 
de entender. Un buen ejemplo es la clase Car: 

//: C14:Car.cpp 
// Public composition 

class Engine { 
public: 

void start() const {} 
void rev() const {} 
void stop() const {} 

} ; 


class Wheel { 
public: 

void inflate (int psi) const {} 

} ; 


class Window { 
public: 

void rollup() const {} 
void rolldown() const {} 


class Door { 
public: 

Window window; 

void open() const {} 

void close() const {} 


class Car { 
public: 

Engine engine; 

Wheel wheel[4]; 

Door left, right; // 2-door 

} ; 

int main() { 

Car car; 

car.left.window.rollup (); 
car.wheel[0],inflate(72); 

} ///:- 


Como la composicion de Car es parte del analisis del problema (y no una simple 
capa del diseno), hace publicos los miembros y ayudan al programador a entender 
como se utiliza la clase y requiere menos complejidad de codigo para el creador de 
la clase. 

Si piensa un poco, observara que no tiene sentido componer un Car usando un 
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objeto "vehiculo” - un coche no contiene un vehiculo, es un vehiculo. La relacion 
"es-un" es expresado con la herencia y la relacion "tiene un" es expresado con la 
composicion. 

Subtipado 

Ahora suponga que desea crear un objeto del tipo ifstream que no solo abre un 
fichero sino que tambien guarde el nombre del fichero. Puede usar la composicion e 
alojar un objeto ifstream y un string en la nueva clase: 

//: Cl4:FNamel.cpp 

// An fstream with a file name 

#include "../require.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

class FNamel { 
ifstream file; 
string fileName; 
bool named; 
public: 

FNamel() : named (false) {} 

FNamel (const strings fname) 

: fileName(fname), file(fname.c_str()) { 

assure(file, fileName); 
named = true; 

} 

string name() const { return fileName; } 
void name (const strings newName) { 

if (named) return; // Don't overwrite 
fileName = newName; 
named = true; 

1 

operator ifstreamSO { return file; } 

} ; 


int main () { 

FNamel file("FNamel.cpp"); 
cout << file.name() << endl; 

// Error: close () not a member: 
//! file.close (); 

} ///:~ 


Sin embargo, existe un problema. Se intenta permitir el uso de un objeto FNamel 
en cualquier lugar donde se utilice un objeto ifstream, incluyendo una conversion 
automatica del tipo desde FNamel a ifstream&. Pero en main, la lfnea 

file.close (); 


no compilara porque la conversion automatica de tipo solo ocurre cuando se lla¬ 
ma a la funcion, no durante la seleccion del miembro. Por ello, esta manera no fun- 
cionara. 
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Una segunda manera es anadir la definicion Close() a FNamel: 

void close() { file.Close(); } 

Esto funcionara si solo existen unas cuantas funciones a las que se desea hacer 
funcionar como una clase ifstream. En este caso, solo una parte de la clase y la com¬ 
posicion apropiada. 

Pero ^que ocurre si se quiere que todo funcione como la clase deseada? A eso se le 
llama subtipos porque esta creando un nuevo tipo desde uno ya existente y lo que se 
quiere es que el nuevo tipo tenga la misma interfaz que el tipo existente (ademas de 
otras funciones que se deseen anadir) para que se pueda utilizar en cualquier lugar 
donde se utilizaba el tipo existente. Aqul es donde la herencia es esencial. Puede ver 
que el subtipo resuelve perfectamente el problema anterior: 

//: C14:FName2.cpp 
// Subtyping solves the problem 

#include /require.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

class FName2 : public ifstream { 
string fileName; 
bool named; 
public: 

FName2() : named (false) {} 

FName2 (const strings fname) 

: ifstream(fname.c_str()), fileName(fname) { 
assure (*this, fileName); 
named = true; 

} 

string name() const { return fileName; } 
void name (const strings newName) { 

if (named) return; // Don't overwrite 
fileName = newName; 
named = true; 


} ; 


int main() { 

FName2 file("FName2.cpp"); 

assure(file, "FName2.cpp"); 

cout << "name: " << file.name() << endl; 

string s; 

getline (file, s); // These work too! 
file.seekg(-200, ios::end); 
file.close() ; 

} ///:- 


Ahora cualquier funcion que este disponible para el objeto sfstream tambien es¬ 
ta disponible para el objeto FName2. Asimismo se observan funciones no miembro 
como getline() que esperan un objeto ifstream y que pueden funcionar con un objeto 
FName2. Esto es porque FName2 es un tipo de ifstream; esto no significa simple- 
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mente que lo contiene. Esto es un tema muy importante que sera explorado al final 
de este capitulo y el siguiente. 

Herencia privada 

Puede heredar utilizando una clase base de forma privada borrando public en 
la lista de la clase base o explicitamente utilizando private (definitivamente la mejor 
politica a tomar pues indica al usuario lo que desea hacer). Cuando se hereda de for¬ 
ma privada, esta "implementado en terminos de", esto es, se esta creando una nueva 
clase que tiene todos los datos y funcionalidad de la clase base, pero la funcionalidad 
esta oculta, solo una parte de capa de implementacion. La clase derivada no tiene ac- 
ceso a la capa de funcionalidad y un objeto no puede ser creado como instancia de 
la clase base (como ocurrio en FName2.cpp). 

Se sorprendera del proposito de la herencia privada, porque la alternativa, usar 
la composicion para crear un objeto privado en la nueva clase parece mas apropia- 
da. La herencia privada esta incluida para completar el lenguaje pero para reducir 
confusion, normalmente se usara la composicion en vez de la herencia privada. Sin 
embargo, existen ocasiones donde se desea el mismo interfaz como la clase base y 
anular tratamiento del objeto. La herencia privada proporciona esta habilidad. 


14.5.2.2.1. Publicar los miembros heredados de forma privada Cuando se he¬ 
reda de forma privada, todos los miembros publicos de la clase base llegan como 
privados. Si desea que cualquiera de ellos sea visible, solo use sus nombres (sin argu- 
mentos o valores de retorno) junto con la palabra clave using en una seccion publica 
de la clase derivada: 

//: C14:Privatelnheritance.cpp 

class Pet { 
public: 

char eat() const { return 'a'; } 

int speak () const { return 2; } 

float sleep () const { return 3.0; } 

float sleep (int) const { return 4.0; } 

} ; 


class Goldfish : Pet { // Private inheritance 

public: 

using Pet::eat; // Name publicizes member 
using Pet::sleep; // Both members exposed 


int main() { 

Goldfish bob; 
bob.eat(); 
bob.sleep (); 
bob.sleep(1); 

//! bob.speak ();// Error: private member function 
} /// : ~ 


Asi, la herencia privada es util si desea esconder parte de la funcionalidad de la 
clase base. 

Fijese que si expone el nombre de una funcion sobrecargada, expone todas las 
versiones sobrecargadas de la funcion en la clase base. 
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Debe pensar detenidamente antes de utilizar la herencia privada en vez de la 
composicion; la herencia privada tiene complicaciones particulares cuando son com- 
binadas con la identificacion de tipos en tiempo de ejecucion (es un tema de un ca¬ 
pitulo en el volumen 2, disponible en www.BruceEckel.com) 


14.6. Protected 

Ahora que ya sabe que es la herencia, la palabra reservada protected ya tiene sig- 
nificado. En un mundo ideal, los miembros privados siempre serian fijos-y-rapidos, 
pero en los proyectos reales hay ocasiones cuando se desea ocultar algo a todo el 
mundo y todavia permitir accesos a los miembros de la clase derivada. La palabra 
clave protected es un movimiento al pragmatismo: este dice "Esto es privado como la 
clase usuario en cuestion, pero disponible para cualquiera que hereda de esta clase. 

La mejor manera es dejar los miembros de datos privados - siempre debe pre- 
servar su derecho de cambiar la capa de implementation. Entonces puede permitir 
acceso controlado a los herederos de su clase a traves de funciones miembro prote- 
gidas: 

//: C14:Protected.cpp 
// The protected keyword 

#include <fstream> 
using namespace std; 

class Base { 
int i; 
protected: 

int read() const { return i; } 
void set (int ii) { i = ii; } 

public: 

Base (int ii = 0) : i(ii) {} 

int value (int m) const { return m*i; } 

} ; 


class Derived : public Base { 
int j; 
public: 

Derived (int jj = 0) : j(jj) {} 

void change (int x) { set (x); } 

} ; 


int main () { 

Derived d; 
d.change (10); 

} ///:~ 


Encontrara ejemplos de la necesidad de uso de protected mas adelante y en el 
volumen 2. 


14.6.1. Herencia protegida 

Cuando se hereda, por defecto la clase base es privada, que significa que todos 
las funciones miembro publicas son privadas para el usuario en la nueva clase. Nor- 
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malmente, heredara publicamente para que el interfaz de la clase base sea tambien 
el interfaz de la clase derivada. Sin embargo, puede usar la palabra clave protected 
durante la herencia. 

Derivar de forma protegida significa "implementado en terminos de" para otras 
clases pero "es-una" para las clases derivadas y amigas. Es algo que no utilizara muy 
a menudo, pero esta en el lenguaje para completarlo. 


14.7. Herencia y sobrecarga de operadores 

Excepto el operador de asignacion, el resto de operadores son heredados automa- 
ticamente en la clase derivada. Esto se puede demostrar heredando de C12:Byte.h: 

//: C14:Operatorlnheritance.cpp 
// Inheriting overloaded operators 

#include " . ./C12/Byte.h" 

#include <fstream> 

using namespace std; 

ofstream out("ByteTest.out"); 

class Byte2 : public Byte { 
public: 

// Constructors don't inherit: 

Byte2(unsigned char bb = 0) : Byte(bb) {} 

// operator= does not inherit, but 

// is synthesized for memberwise assignment. 

// However, only the SameType = SameType 
// operator= is synthesized, so you have to 
// make the others explicitly: 

Byte2& operator=(const Bytes right) { 

Byte::operator=(right); 
return *this; 

1 

Byte2s operator=(int i) { 

Byte::operator=(i); 
return *this; 

} 

} ; 

// Similar test function as in C12:ByteTest.cpp: 
void k(Byte2s bl, Byte2& b2) { 

bl = bl * b2 + b2 % bl; 

#define TRY2(OP) \ 

out << "bl = bl.print(out); \ 

out << ", b2 = b2.print (out); \ 

out << bl " #OP " b2 produces \ 

(bl OP b2).print(out); \ 
out << endl; 

bl = 9; b2 = 47; 

TRY2(+) TRY2(-) TRY2(*) TRY2(/) 

TRY2(%) TRY2( A ) TRY2(&) TRY2(|) 

TRY2(<<) TRY2(>>) TRY2(+=) TRY2(-=) 

TRY2(*=) TRY2(/=) TRY2(%=) TRY2( A =) 

TRY2 ( S = ) TRY2 ( | =) TRY2(>>=) TRY2(«=) 


423 
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TRY2(=) // Assignment operator 

// Conditionals: 

#define TRYC2(OP) \ 

out << "bl = bl.print(out) ; \ 
out << ", b2 = b2.print (out); \ 
out << bl " #OP " b2 produces \ 

out << (bl OP b2); \ 
out << endl; 

bl = 9; b2 = 47; 

TRYC2(<) TRYC2(>) TRYC2(==) TRYC2(!=) TRYC2(<=) 

TRYC2(>=) TRYC2(& &) TRYC2(| |) 

// Chained assignment: 

Byte2 b3 = 92; 

bl = b2 = b3; 


int main () { 

out << "member functions:" << endl; 
Byte2 bl (47), b2 (9); 
k(bl, b2); 

} ///:- 


El codigo de prueba anterior es identico a C12:ByteTest.cpp excepto que Byte2 se 
usa en vez de Byte. De esta forma todos los operadores son verificados para trabajar 
con Byte2 a traves de la herencia. 

Cuando examina la clase Byte2, vera que se ha definido explicitamente el cons¬ 
tructor y que solo se ha credo el operator= que asigna un Byte2 a Byte2; cualquier 
otro operador de asignacion tendra que se realizado por usted. 


14.8. Herencia multiple 

Si puede heredar de una clase, tendria sentido heredar de mas de una clase a la 
vez. De hecho, puede hacerlo, pero si tiene sentido como parte del diseno es un tema 
que todavia se esta debatiendo. Una cosa en que generalmente se esta de acuerdo: 
debe evitar intentarlo hasta que haya programado bastante y comprenda el lenguaje 
en profundidad. Por ahora, probablemente no le importa cuando debe absolutamen- 
te utilizar la herencia multiple y siempre puede utilizar la herencia simple 

Inicialmente, la herencia multiple parece bastante simple: se ahade las clases en la 
lista de clases base durante la herencia separadas por comas. Sin embargo, la heren¬ 
cia multiple introduce un numero mayor de ambigiiedades, y por eso, un capitulo 
del Volumen 2 hablara sobre el tema. 


14.9. Desarrollo incremental 

Una de las ventajas de la herencia y la composicion es el soporte al desarrollo 
incremental permitiendo introducir nuevo codigo sin causar fallos en el ya existente. 
Si aparecen fallos, estos son rectificados con nuevo codigo. Heredando de (o com- 
poniendo con) clases y funciones existentes y anadiendo miembros de datos y fun- 
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ciones miembros (y redefiniendo las funciones existentes durante la herencia) puede 
dejar el codigo existente - por otro que todavia se esta usando - que alguien todavia 
lo este utilizando. Si ocurre algun error, ahora sabe donde esta el nuevo codigo, y 
entonces podra leerlo mas rapido y facilmente que si lo hubiera modificado en el 
cuerpo del codigo existente. 

Es sorprendente como las clases son limpiamente separadas. Incluso no es ne- 
cesario anadir el codigo fuente con funciones miembros para reutilizar el codigo, 
solamente el fichero de cabecera describiendo la clase y el fichero objeto o el fiche- 
ro de libreria con las funciones miembros compiladas. (Esto es valido tanto para la 
herencia como para la composition.) 

Esto es importante para hacer que el desarrollo sea un proceso incremental, como 
el aprendizaje de una persona. Puede hacer tantos analisis como desee pero todavia 
no sabra todas las respuestas cuando configure un proyecto. Tendra mas exito y un 
progresion inmediata - si su proyecto empieza a crecer como una criatura organi- 
ca, evolutiva, parecera mas bien que esa construyendo algo como un rascacielos de 
cristal [52] 

Sin embargo la herencia es una tecnica util para la experimentation, en algun 
punto donde las cosas estan estabilizadas, necesita echar un nuevo vistazo a la jerar- 
quia de clases para colapsarla dentro de una estructura sensible [53]. Recuerde que, 
por encima de todo, la herencia significa expresar una relacion que dice "Esta nueva 
clase es un tipo de esta vieja". Su programa no debe preocuparse de como mueve 
pedazos de bits por alrededor, en vez debe crear y manipular objetos de varios tipos 
para expresar un modelo en los terminos dados para su problema. 


14.10. Upcasting 

Anteriormente en este capitulo, observo como un objeto de una clase que deri- 
vaba de ifstream tenia todas las caracteristicas y conductas de un objeto ifstream. En 
FName2.cpp, cualquier funcion miembro de ifstream podria ser llamada por cual- 
quier objeto FName2. 

El aspecto mas importante de la herencia no es proporcionar nuevas funciones 
miembro a la nueva clase. Es la relacion expresada entre la nueva clase y la clase 
base. Esta relacion puede ser resumida diciendo "La nueva clase es de un tipo de 
una clase existente". 

Esta no es una description fantasiosa de explicar la herencia - esta directamente 
soportada por el compilador. Un ejemplo, considere una clase base llamada Instru¬ 
ment que representa instrumentos musicales y una clase derivada llamada Wind. 
Dado que la herencia significa que todas las funciones en la clase base estan tambien 
disponibles en la clase derivada, cualquier mensaje que envie a la clase base pue¬ 
de ser tambien enviado desde la derivada. Entonces si la clase Instrument tiene una 
funcion miembro play(), tambien existira en los instrumentos de Wind. Esto signifi¬ 
ca precisamente que un objeto Wind es un tipo de Instrument. El siguiente ejemplo 
muestra como el compilador soporta esta idea: 

//: C14:Instrument.cpp 
// Inheritance & upcasting 

enum note { middleC, Csharp, Cflat }; // Etc. 

class Instrument { 

public: 

void play (note) const {} 
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// Wind objects are Instruments 
// because they have the same interface: 
class Wind : public Instrument {}; 

void tune(Instruments i) { 

i.play(middleC); 

} 


int main() { 

Wind flute; 

tune (flute); // Upcasting 
} ///:~ 


Lo interesante en este ejemplo es la funcion tune(), que acepta una referenda Ins¬ 
trument. Sin embargo, en main() la funcion tune() se llama utilizando una referenda 
a un objeto Wind. Dado que C++ es un muy peculiar sobre la comprobacion de tipos, 
parece extrano que una funcion que acepta solo un tipo pueda aceptar otro tipo, al 
menos que sepa que un objeto Instrument es tambien un objeto Instrument. 


14.10.1. <jPor que «upcasting»? 

La razon de este termino es historica y esta basada en la manera en que se dibuja 
la herencia: con la ralz en la parte superior de la pagina y hacia abajo (por supuesto 
que puede pintar su diagrama de cualquier modo que le sea util). El diagrama para 

Instrument. cpp es: 



Figura 14.1: Upcasting 


El hecho de pasar de la clase derivada a la clase base, esto es, desplazarse hacia 
arriba en el diagrama de la herencia, es normalmente conocido como upcasting. Up¬ 
casting es siempre seguro porque se esta desplazando de un tipo desde un tipo mas 
especifico a otro tipo mas general. - unicamente puede ocurrir es que la interfaz de 
la clase pierda algunas funciones miembro, pero no ganarlas. Esto es porque el com- 
pilador permite el upcasting sin ninguna conversion explicita o notacion especial. 


14.10.2. FIXME Upcasting y el constructor de copia 

Si permite que el compilador cree un constructor copia de una clase derivada, 
este llamara automaticamente al constructor copia de la clase base, y entones ,a los 
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constructores copia para todos los miembros objeto (o realizara una copia de bits en 
los tipos predefinidos) entonces conseguira la conducta correcta: 

//: C14:CopyConstructor.cpp 

// Correctly creating the copy-constructor 

#include <iostream> 

using namespace std; 

class Parent { 
int i; 
public: 

Parent (int ii) : i (ii) { 

cout << "Parent (int ii)\n"; 

} 

Parent (const Parents b) : i(b.i) { 
cout << "Parent(const Parents)\n"; 

} 

Parent () : i(0) { cout << "Parent ()\n"; } 

friend ostreams 

operator« (ostreamS os, const Parents b) { 
return os << "Parent: " << b.i << endl; 


} ; 


class Member { 
int i; 
public: 

Member (int ii) : i (ii) { 

cout << "Member(int ii)\n"; 

) 

Member (const Members m) : i(m.i) { 
cout << "Member(const Members)\n"; 

} 

friend ostreams 

operator« (ostreams os, const Members m) { 
return os << "Member: " << m.i << endl; 


} ; 


class Child : public Parent { 
int i; 

Member re¬ 
public : 

Child (int ii) : Parent (ii), i(ii), m(ii) { 
cout << "Child(int ii)\n"; 

} 

friend ostreams 

operator« (ostreams os, const Childs c){ 
return os << (Parents)c << c.m 

<< "Child: " << c.i << endl; 


} ; 


int main () { 

Child c (2); 

cout << "calling copy-constructor: " << endl; 
Child c2 = c; // Calls copy-constructor 
cout << "values in c2:\n" << c2; 
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} /// : ~ 


El operador« de Child es interesante por la forma en que llama al operador« 
del padre dentro de este: convirtiendo el objeto Child a Parent& (si lo convierte a un 
objeto de la clase base en vez de una referenda, probablemente obtendra resultados 
no deseados) 

return os << (Parents)c << c.m 

Dado que el compilador lo ve como Parent, este llama al operador<< Parent. 

Puede observar que Child no tiene explidtamente definido un constructor copia. 
El compilador crea el constructor copia (es una de las cuatro funciones que sintetiza, 
junto con el constructor del defecto - si no creas a ninguna constructores - el opera¬ 
tor y el destructor) llamando el constructor copia de Parent y el constructor copia 
de Member. Esto muestra la siguiente salida 


Parent(int ii) 

Member(int ii) 

Child(int ii) 
calling copy-constructor: 
Parent(const Parents) 
Member(const Members) 
values in c2: 

Parent: 2 
Member: 2 
Child: 2 


Sin embargo, si escribe su propio constructor copia para Child puede tener un 
error inocente y funcionar incorrectamente: 

Child(const Childs c) : i(c.i), m(c.m) {} 

entonces el constructor por defecto sera llamado automaticamente por la clase 
base por parte de Child, aqui es donde el compilador muestra un error cuando no 
tienen otra (recuerde que siempre algun constructor se ejecuta para cada objeto, sin 
importar si es un subobjeto de otra clase). La salida sera entonces: 


Parent(int ii) 

Member(int ii) 

Child(int ii) 

calling copy-constructor: 

Parent() 

Member(const Members) 
values in c2: 

Parent: 0 
Member: 2 
Child: 2 


Esto probablemente no es lo que espera, generalmente deseara que la parte de la 
clase base sea copiada del objeto existente al nuevo objeto como parte del constructor 
copia. 

Para arreglar el problema debe recordar como funciona la llamada al construc¬ 
tor copia de la clase base (como el compilador lo hace) para que escriba su propio 
constructor copia. Este puede parecer un poco extrano a primera vista pero es otro 
ejemplo de upcasting. 
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Child(const Childs c) 

: Parent(c), i(c.i), ra(c.m) { 
cout << "Child(Childs)\n" ; 

} 


La parte extraha es como el constructor copia es ejecutado: Parent(c). <j,Que sig- 
nifica pasar un objeto Child al constructor padre? Child hereda de Parent, entonces 
una referenda de Child es una referenda Parent. El constructor copia de la clase ba¬ 
se convierte a una referencia de Child a una referenda de Parent y la utiliza en el 
construction de la copia. Cuando escribe su propio constructor copia la mayoria de 
ocasiones deseara lo mismo. 


14.10.3. Composicion vs. herencia FIXME (revisited) 

Una de las maneras mas claras de determinar cuando debe utilizar la composi¬ 
cion o la herencia es preguntando cuando sera necesaria la conversion desde su nue- 
va clase. Anteriormente, en esta capitulo, la clase Stack fue especializada utilizando 
la herencia. Sin embargo, los cambios en StringStack seran utilizados son como con- 
tenedores de string y nunca seran convertidos, pero ello, es mucho mas apropiado 
utilizas la alternativa de la composicion. 

//: C14:InheritStack2.cpp 
// Composition vs. inheritance 

#include "../C09/Stack4.h" 

#include "../require.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

class StringStack { 

Stack stack; // Embed instead of inherit 

public: 

void push(string* str) { 
stack.push(str) ; 

} 

string* peek() const { 

return (string*)stack.peek(); 

} 

string* pop() { 

return (string*)stack.pop(); 


} ; 


int main () { 

ifstream in("InheritStack2.cpp"); 
assure (in, "InheritStack2.cpp"); 
string line; 

StringStack textlines; 
while (getline(in, line)) 

textlines.push (new string(line)); 
string* s; 

while((s = textlines.pop()) != 0) // No cast! 

cout << *s << endl; 

} ///:~ 
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El fichero es identico a InheritStack.cpp, excepto que un objeto Stack es alojado en 
StringStack y se utilizan las funciones miembros para llamarlo. No se consume tiem- 
po o espacio porque el subobjeto tiene el mismo tamano y todas las comprobaciones 
de tipos han ocurrido en tiempo de compilacion. 

Sin embargo, esto tiende a confusion, podria tambien utilizar la herencia privada 
para expresar "implementado en terminos de". Esto tambien resolveria el problema 
de forma adecuada. Un punto importante es cuando la herencia multiple puede ser 
garantizada. En este caso, si observa un diseno en que la composicion pueda utili- 
zarse en vez de la herencia, debe eliminar la necesidad de utilizar herencia multiple. 


14.10.4. FIXME Upcasting de punteros y referencias 

En Instrument.cpp, la conversion ocurre durante la llamada a la funcion - un obje¬ 
to Wind fuera de la funcion se toma como referenda y se convierte en una referenda 
Instrument dentro de la funcion. La conversion puede tambien ocurrir durante una 
asignacion a un puntero o una referenda. 

Wind w; 

Instrument* ip = &w; // Upcast 
Instruments ir = w; // Upcast 


Como en la llamada a la funcion, ninguno de estos casos requiere una conversion 
explicita. 


14.10.5. Una crisis 

Por supuesto, cualquier conversion pierde la informacion del tipo sobre el objeto. 
Si dice 

Wind w; 

Instrument* ip = Sw; 


el compilador puede utilizar ip solo como un puntero a Instrumento y nada mas. 
Esto es, este no puede conocer que ip realmente esta apuntando a un objeto Wind. 
Entonces cuando llame a la funcion miembro play() diciendo 

ip->play(middleC) ; 


el compilador solo puede conocer que la llamada a play() es de un puntero a 
Instrument y llamara a la version de la clase base Instrument: :play() en vez de lo 
que deberia hacer, que es llamar a Wind::play(). Asi, no conseguira una conducta 
adecuada. 

esto es un problema importante; es resulto en el Capitulo 15, introduccion al ter- 
cer pilar de la programacion orientada a objetos: poliformismo (implementado en 
C++ con funciones virtuales). 
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14.11. Resumen 

Herencia y composicion le permiten crear nuevos tipos desde tipos existentes y 
ambos incluyen subobjetos de tipos existentes dentro del nuevo tipo. Sin embargo, 
normalmente, utilizara la composicion para reutilizar tipos existentes como parte de 
la capa de implementation de un nuevo tipo y la herencia cuando desea forzar al 
nuevo tipo a ser del mismo tipo que la clase base (la equivalencia de tipos garantiza 
la equivalencia de la interfaz). Como las clases derivadas tienen el interfaz de la clase 
base, esta puede ser convertidas a la base, lo cual es critico para el poliformismo 
como vera el Capitulo 15. 

Aunque la reutilizacion de codigo a traves de la composicion y la herencia es 
muy util para el desarrollo rapido de proyectos, generalmente deseara redisenar su 
jerarquia de clases antes de permitir a otros programadores dependan de ella. Su 
objetivo es crear una jerarquia en que cada clase tenga un uso especifico y sin ser 
demasiado grande (esforzandose mas en la funcionalidad que en la dificultad de la 
reutilizacion...), ni pequena, (no se podra usar por si mismo o sin anadir funcionali¬ 
dad). 


14.12. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Modificar Car.cpp para que herede desde una clase llamada Vehicle, colocando 
correctamente las funciones miembro en Vehicle (esto es, anadir algunas fun- 
ciones miembro). Anada un constructor (no el de por defecto) a Vehicle, que 
debe ser llamado desde dentro del constructor Car 

2. Crear dos clases, A y B, con constructor por defectos notificandose ellos mis- 
mos. Una nueva clase llamada C que hereda de A, y cree un objeto miembro B 
dentro de C, pero no cree un constructor para C. Cree un objeto de la clase C y 
observe los resultados. 

3. Crear una jerarquia de clases de tres niveles con constructores por defecto y 
con destructores, ambos notificandose utilizando cout. Verificar que el objeto 
mas alto de la jerarquia, los tres constructores y destructores son ejecutados 
automaticamente. Explicar el orden en que han sido realizados. 

4. Modificar Combined.cpp para anadir otro nivel de herencia y un nuevo objeto 
miembro. Anadir el codigo para mostrar cuando los constructores y destructo¬ 
res son ejecutados. 

5. En Combined.cpp, crear una clase D que herede de B y que tenga un objeto 
miembro de la clase C. Anadir el codigo para mostrar cuando los constructores 
y los destructores son ejecutados. 

6. Modificar Order.cpp para anadir otro nivel de herencia Derived3 con objetos 
miembro de la clase Member4 y Member5. Compruebe la salida del programa. 

7. En NameHidding.cpp, verificar que Derived2, Derived3 y Derived4, ninguna 
version de la clase base de f() esta disponible. 
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8. Modificar NameHiding.cpp anadiendo tres funciones sobrecargadas llamadas 
h() en Base y mostrar como redefiniendo una de ellas en una clase derivada 
oculta las otras. 

9. Crear una clase String Vector que herede de vector<void*> y redefinir pushjback 
y el operador [] para aceptar y producir string*. ^Que ocurre si intenta utilizar 
push_back() un void*? 

10. Escribir una clase que contenga muchos tipos y utilice una llamada a una fun- 
cion pseudo-constructor que utiliza la misma sintaxis de un constructor.Utilizarla 
en el constructor para inicializar los tipos. 

11. Crear una clase llamada Asteroid. Utilizar la herencia para especializar la clase 
PStash del capitulo 13 (PStash.h y PStash.cpp) para que la acepte y retorne 
punteros a Asteroid. Tambien modifique PStashTest.cpp para comprobar sus 
clases. Cambiar la clase para que PStash sea un objeto miembro. 

12. Repita el ejercicio 11 con un vector en vez de la clase PStash. 

13. En SynthesizedFunctions.cpp, modifique Chess para proporcionarle un cons¬ 
tructor por defecto, un constructor copia y un operador de asignacion. Demos- 
trar que han sido escritos correctamente. 

14. Crear dos clases llamadas Traveler y Pager sin constructores por defecto, pero 
con constructores que toman un argumento del tipo string, el cual simplemente 
lo copia a una variable interna del tipo string. Para cada clase, escribir correc¬ 
tamente un constructor copia y el operador de asignacion. Entonces cree la cla¬ 
se BusinessTraveler que hereda de Traveler y crear ub objeto miembro Pager 
dentro ella. Escribir correctamente el constructor por defecto, un constructor 
que tome una cadena como argumento, un constructor copia y un operador de 
asignacion. 

15. Crear una clase con dos funciones miembro estaticas. Herede de estas clases y 
redefina una de las funciones miembro. Mostrar que la otra funcion se oculta 
en la clase derivada. 

16. Mejorar las funciones miembro de ifstream. En FName2.cpp, intentar supri- 
mirlas del objeto file. 

17. Utilice la herencia privada y protegida para crear dos nuevas clases desde la 
clase base. Intente convertir los objetos de las clases derivadas en la clase base. 
Explicar lo que ocurre. 

18. En Protected.cpp, anadir una funcion miembro en Derived que llame al miem¬ 
bro protegido de Base read(). 

19. Cambiar Protected.cpp para que Derived utilice herencia protegida. Comprue- 
be si puede llamar a value() desde un objeto Derived. 

20. Crear una clase llamada Spaceship con un metodo fly(). Crear Shuttle que here¬ 
da de Spaceship y anadir el metodo land(). Creat un nuevo Shuttle, convertirlo 
por puntero o referenciaa Spaceship e intente llamar al metodo land(). Explicar 
los resultados. 

21. Modificar Instrument.cpp para anadir un metodo prepare() a Instrument. Lla¬ 
mar a prepare () dentro de tuneQ. 
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22. Modificar Instrument.cpp para que play() muestre un mensaje con cout y que 
Wind redefina play() para que muestra un mensaje diferente con cout. Execu¬ 
te el programa y explique porque probamenteble no deseara esta conducta. 
Ahora ponga la palabra reservada virtual (la cual aprendera en el capitulo 15) 
delante de de la declaration de play en Instrument y observe el cambio en el 
comportamiento. 

23. En CopyConstructor.cpp, herede una nueva clase de Child y proporcionarle un 
miembro m. Escribir un constructor correcto, un constructor copia, operator= 
y operator<< de ostreams y comprobar la clase en mainQ. 

24. Tomar como ejemplo CopyConstructor.cpp y modifiquelo anadiendo su pro- 
pio constructor copia a Child sin llamar el constructor copia de clase base y 
comprobar que ocurre. Arregle el problema anadiendo una llamada explicita 
al constructor copia de la clase base en la lista de initialization del constructor 
del constructor copia de Child. 

25. Modificar InheritStack2.cpp para utilizar un vector<string> en vez de Stack. 

26. Crear una clase Rock con un constructor por defecto, un constructor copia y 
un operador de asignacion y un destructor, todos ellos mostrandose para saber 
que han sido ejecutados. En main(), crear un vector<Rock> (esto es, tener obje- 
tos Rock por valor) y anadir varios Rocks. Ejecutar el programa y explicar los 
resultados obtenidos. Fijarse cuando los destructores son llamados desde los 
objetos Rock en el vector. Ahora repita el ejercicio con un vector<Rock*>. ^Es 
posible crear un vector<Rock&>? 

27. En este ejercicio cree un patron de diseno llamado proxy. Comience con la cla¬ 
se base Subject y proportioned tres funciones: f(), g() y h(). Ahora herede una 
clase Proxy y dos clases Implementation! e Implementation de Subject. Proxy 
tendria que contener un puntero a un Suboject y todos los miembros de Proxy 
(usualmente el constructor). En main(), crear dos objetos Proxy diferentes que 
usen las dos implementaciones diferentes. Modificar Proxy para que dinami- 
camente cambie las implementaciones. 

28. Modificar ArrayOperatorNew del Capitulo 13 para mostrar que si deriva de 
Widget, la reserva de memoria todavia funciona correctamente. Explicar por¬ 
que la herencia en Framis.cpp no funcionaria correctamente. 

29. Modificar Framis.cpp del Capitulo 13 para que herede de Framis y crear nue- 
vas versiones de new y delete para su clase derivada. Demostrar como todo 
ello funciona correctamente. 
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15: Polimorfismo y Funciones vir- 
tuales 

El Polimorfismo (implementado en C++ con funciones virtua- 
les) es la tercera caracteristica esencial de un lenguaje orientado a 
objetos, despues de la abstraction de datos y la herencia. 

De hecho, nos provee de otra dimension para la separation entre interfaz y la 
implementacion, desacoplando el que del como. El Polimorfismo permite mejorar la 
organization del codigo y su legibilidad asi como la creation de programas exten- 
sibles que pueden "crecer” no solo durante el desarrollo del proyecto, si no tambien 
cuando se deseen nuevas caracteristicas. 

La encapsulation crea nuevos tipos de datos combinando caracteristicas y com- 
portamientos. El control de acceso separa la interfaz de la implementacion haciendo 
privados (private) los detalles. Estos tipos de organization son facilmente entendi- 
bles por cualquiera que venga de la programacion procedimental. Pero las funciones 
virtuales tratan de desunir en terminos de tipos. En el Capitulo 14, usted vio como la 
herencia permitia tratar a un objeto como su propio tipo o como a su tipo base. Esta 
habilidad es basica debido a que permite a diferentes tipos (derivados del mismo 
tipo base) ser tratados como si fueran un unico tipo, y un unico trozo de codigo es 
capaz de trabajar indistintamente con todos. Las funciones virtuales permiten a un 
tipo expresar sus diferencias con respecto a otro similar si ambos han sido derivados 
del mismo tipo base. Esta distincion se consigue modificando las conductas de las 
funciones a las que se puede llamar a traves de la clase base. 

En este capitulo aprendera sobre las funciones virtuales, empezando con ejem- 
plos simples que le mostrara lo "desvirtual" del programa. 


15.1. Evolucion de los programadores de C++ 

Los programadores de C parecen conseguir pasarse a C++ en tres pasos. A1 prin- 
cipio, como un "C mejorado", debido a que C++ le fuerza a declarar todas las funcio¬ 
nes antes de usarlas y a que es mucho mas sensible a la forma de usar las variables. 
A menudo se pueden encontrar errores en un programa C simplemente recompilan- 
dolo con un compilador de C++. 

El segundo paso es la "programacion basada en objetos", que significa que se pue¬ 
den ver facilmente los beneficios de la organization del codigo al agrupar estructuras 
de datos junto con las funciones que las manejan, la potencia de los constructores y 
los destructores, y quizas algo de herencia simple. La mayoria de los programado¬ 
res que han trabajado durante un tiempo con C ven la utilidad de esto porque es 
lo que intentan hacer cuando crean una libreria. Con C++ usted recibe la ayuda del 
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compilador. 

Usted se puede encontrar atascado en el nivel de "programacion basada en obje- 
tos" debido a que es de facil acceso y no requiere mucho esfuerzo mental. Es tambien 
sencillo sentir como esta creando tipos de datos - usted hace clases y objetos, envia 
mensajes a esos objetos, y todo es bonito y pulcro. 

Pero no sea tonto. Si se para aqui, se esta perdiendo una de las mas importantes 
partes del lenguaje, que significa el salto a la verdadera programacion orientada a 
objetos. Y esto se consigue unicamente con las funciones virtuales. 

Las funciones virtuales realzan el concepto de tipo en lugar de simplemente en- 
capsular codigo dentro de estructuras y dejarlo detras de un muro, por lo que son, sin 
lugar a dudas, el concepto mas dificil a desentranar por los nuevos programadores 
en C++. Sin embargo, son tambien el punto decisivo para comprender la programa¬ 
cion orientada a objetos. Si no usa funciones virtuales, todavia no entiende la POO. 

Debido a que las funciones virtuales estan intimamente unidas al concepto de 
tipo, y los tipos son el nucleo de la programacion orientada a objetos, no existe ana- 
logia a las funciones virtuales dentro de los lenguajes procedurales. Como programa- 
dor procedural, usted no tiene referente con el que comparar las funciones virtuales, 
al contrario de las otras caracteristicas del lenguaje. Las caracteristicas de un len¬ 
guaje procedural pueden ser entendidas en un nivel algoritmico, pero las funciones 
virtuales deben ser entendidas desde el punto de vista del diseno. 


15.2. Upcasting 

En el Capitulo 14 se vio como un objeto puede ser usado como un objeto de su 
propio tipo o como un objeto de su tipo base. Ademas el objeto puede ser manejado a 
traves de su tipo base. Tomar la direccion de un objeto (o un puntero o una referenda) 
y tratarlo como la direccion de su tipo base se conoce como upcasting 1 debido al 
camino que se genera en los arboles de herencia que se suelen pintar con la clase 
base en la cima. 

Tambien se vio surgir un problema el cual esta encarnado en el siguiente codigo: 

//: C15:Instrument2.cpp 
// Inheritance & upcasting 

#include <iostream> 

using namespace std; 

enum note { middleC, Csharp, Eflat }; // Etc. 

class Instrument { 

public: 

void play(note) const { 

cout << "Instrument::play" << endl; 



// Wind objects are Instruments 
// because they have the same interface: 
class Wind : public Instrument { 

1 N del T: Por desgracia upcasting es otro de los terminos a los que no he encontrado una traduc- 
cion convincente (^amoldar hacia arriba??) y tiene el agravante que deriva de una expresion ampliamen- 
te usada por los programadores de C CQuien no ha hecho nunca un cast a void* ;-) ?. Se aceptan 
sugerencias. 
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public: 

// Redefine interface function: 
void play (note) const { 

cout << "Wind::play" << endl; 


} ; 


void tune(Instruments i) { 
i.play(middleC); 

} 


int main() { 

Wind flute; 

tune (flute); // Upcasting 
} ///:- 


La funcion tune () acepta (por referenda) un Instrument, pero tambien acepta 
cualquier cosa que derive de Instrument. En el main (), se puede ver este compor- 
tamiento cuando se pasa un objeto Wind a afinar () sin que se necesite ningun 
molde. La interfaz de Instrument tiene que existir en Wind, porque Wind hereda 
sus propiedades de Instrument. Moldear en sentido ascendente ( Upcasting ) de W- 
ind a Instrument puede "reducir" la interfaz, pero nunca puede ser menor que la 
interfaz de Instrument. 

Los mismos argumentos son ciertos cuando trabajamos con punteros; la linica 
diferencia es que el usuario debe indicar la direccion de los objtos de forma explicita 
cuando se pasen a una funcion. 


15.3. El problema 

El problema con Instrument2 . cpp puede verse al ejecutar el programa. La sa- 
lida es Instrument: :play. Claramente, esta no es la salida deseada, porque el 
objeto es actualmente un Wind y no solo un Instrument. La llamada deberia pro- 
ducir un Wind: : play. Por este motivo, cualquier objeto de una clase que derive de 
la clase Instrument deberia usar su propia version de play (), de acuerdo a la 
situacion. 

El comportamiento de Instrument2 . cpp no es sorprendente dada la aproxi- 
macion de C a las funciones. Para entender el resultado es necesario comprender el 
concepto de binding (ligadura). 


15.3.1. Ligadura de las llamadas a funciones 

Conectar una llamada a una funcion al cuerpo de la funcion se conoce como bin¬ 
ding (vincular). Cuando la vinculacion se realiza antes de ejecutar el programa (por 
el compilador y el linker), se la conoce como early binding (ligadura temprana). Puede 
no haber escuchado anteriormente este termino debido a que no es posible con los 
lenguajes procedurales: los compiladores de C solo admiten un tipo de vinculacion 
que es la vinculacion anticipada. 

El problema en el programa anterior es causado por la vinculacion anticipada 
porque el compilador no conoce la correcta funcion a la que deberia llamar cuando 
solo es una direccion de Instrument. 
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La solution se conoce como ligadura tardia (late binding), que significa que la li- 
gadura se produce en tiempo de ejecucion basandose en el tipo de objeto. Tambien 
es conocida como ligadura dindmica o ligadura en tiempo de ejecucion. Cuando un len- 
guaje implementa la ligadura dinamica debe existir algun tipo de mecanismo para 
determinar el tipo del objeto en tiempo de ejecucion y llamar a la funcion miembro 
apropiada. En el caso de un lenguaje compilado, el compilador todavia no conoce el 
tipo actual del objeto, pero inserta codigo que lo averigua y llama al cuerpo correcto 
de la funcion. El mecanismo de la ligadura dinamica varia de un lenguaje a otro, 
pero se puede imaginar que algun tipo de information debe ser introducida en los 
objetos. Se vera como trabaja posteriormente. 


15.4. Funciones virtuales 

Para que la ligadura dinamica tenga efecto en una funcion particular, C++ necesi- 
ta que se use la palabra reservada virtual cuando se declara la funcion en la clase 
base. La ligadura en tiempo de ejecucion funciona unicamente con las funciones v- 
irtual es, y solo cuando se esta usando una direction de la clase base donde exista 
la funcion virtual, aunque puede ser definida tambien en una clase base anterior. 

Para crear una funcion miembro como virtual, simplemente hay que preceder 
a la declaration de la funcion con la palabra reservada virtual. Solo la declaration 
necesita la palabra reservada virtual, y no la definition. Si una funcion es decla- 
rada como virtual, en la clase base, sera entonces virtual en todas las clases 
derivadas. La redefinition de una funcion virtual en una clase derivada se conoce 
como overriding. 

Hay que hacer notar que solo es necesario declarar la funcion como virtua- 
1 en la clase base. Todas las funciones de las clases derivadas que encajen con la 
declaration que este en la clase base seran llamadas usando el mecanismo virtual. Se 
puede usar la palabra reservada virtual en las declaraciones de las clases derivadas 
(no hace ningun mal), pero es redundante y puede causar confusion. 

Para conseguir el comportamiento deseado de Instrument2 . cpp, simplemente 
hay que ahadir la palabra reservada virtual en la clase base antes de play (). 

//: C15:Instrument!.cpp 

// Late binding with the virtual keyword 

#include <iostream> 

using namespace std; 

enum note { middleC, Csharp, Cflat }; // Etc. 

class Instrument { 

public: 

virtual void play(note) const { 

cout << "Instrument::play" << endl; 


} ; 


// Wind objects are Instruments 
// because they have the same interface: 
class Wind : public Instrument { 

public: 

// Override interface function: 
void play (note) const { 

cout << "Wind::play" << endl; 

} 
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void tune(Instruments i) { 

// ... 

i.play(middleC); 

} 


int main() { 

Wind flute; 

tune (flute); // Upcasting 
} ///:~ 


Este archivo es identico a Instrument2 . cpp excepto por la adicion de la pa- 
labra reservada virtual y, sin embargo, el comportamiento es significativamente 
diferente: Ahora la salida es Wind: : play. 


15.4.1. Extensibilidad 

Con play () definido como virtual en la clase base, se pueden anadir tan- 
tos nuevos tipos como se quiera sin cambiar la funcion play (). En un programa 
orientado a objetos bien disenado, la mayorla de las funciones seguiran el modelo 
de play ( ) y se comunicaran unicamente a traves de la interfaz de la clase base. Las 
funciones que usen la interfaz de la clase base no necesitaran ser cambiadas para 
soportar a las nuevas clases. 

Aqui esta el ejemplo de los instrumentos con mas funciones virtuales y un mayor 
numero de nuevas clases, las cuales trabajan de manera correcta con la antigua (sin 
modificaciones) funcion play (): 

//: C15:Instrument!.cpp 
// Extensibility in OOP 

#include <iostream> 

using namespace std; 

enum note { middleC, Csharp, Cflat }; // Etc. 

class Instrument { 

public: 

virtual void play (note) const { 

cout << "Instrument::play" << endl; 

1 

virtual char* what() const { 
return "Instrument"; 

1 

// Assume this will modify the object: 

virtual void adjust (int) {} 

} ; 


class Wind : public Instrument { 

public: 

void play (note) const { 

cout << "Wind::play" << endl; 

} 

char* what() const { return "Wind"; } 
void adjust (int) {} 

}; 
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class Percussion : public Instrument { 

public: 

void play(note) const { 

cout << "Percussion::play" << endl; 

} 

char* what() const { return "Percussion"; } 
void adjust(int) {} 

} ; 

class Stringed : public Instrument f 

public: 

void play (note) const { 

cout << "Stringed::play" << endl; 

} 

char* what() const { return "Stringed"; } 
void adjust(int) {} 

} ; 

class Brass : public Wind { 
public: 

void play(note) const { 

cout << "Brass::play" << endl; 

} 

char* what() const { return "Brass"; } 

} ; 

class Woodwind : public Wind { 
public: 

void play(note) const { 

cout << "Woodwind::play" << endl; 

} 

char* what() const { return "Woodwind"; } 

} ; 

// Identical function from before: 
void tune(Instruments i) { 

// ... 

i.play(middleC); 


// New function: 

void f(Instruments i) { i.adjust(l); } 

// Upcasting during array initialization: 

Instrument* A[] = { 
new Wind, 
new Percussion, 
new Stringed, 
new Brass, 

) ; 

int main() { 

Wind flute; 

Percussion drum; 

Stringed violin; 

Brass flugelhorn; 

Woodwind recorder; 


440 
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tune (flute); 
tune(drum); 
tune(violin); 
tune (flugelhorn); 
tune(recorder); 
f (flugelhorn); 

} // / : ~ 


Se puede ver que se ha anadido otro nivel de herencia debajo de Wind, pero el 
mecanismo virtual funciona correctamente sin importar cuantos niveles haya. La 
funcion adjust () no esta redefinida ( override ) por Brass y Woodwind. Cuando esto 
ocurre, se usa la definicion mas "cercana” en la jerarqula de herencia - el compilador 
garantiza que exista algnna definicion para una funcion virtual, por lo que nunca 
acabara en una llamada que no este enlazada con el cuerpo de una funcion (lo cual 
seria desatroso). 

El array A [ ] contiene punteros a la clase base Instrument, lo que implica que 
durante el proceso de inicializacion del array habra upcasting. Este array y la funcion 
f () seran usados en posteriores discusiones. 

En la llamada a tune (), el upcasting se realiza en cada tipo de objeto, haciendo 
que se obtenga siempre el comportamiento deseado. Se puede describir como "en- 
viar un mensaje a un objeto y dejar al objeto que se preocupe sobre que hacer con el ". 
La funcion virtual es la lente a usar cuando se esta analizando un proyecto: ^Don- 
de deben estar las clases base y como se desea extender el programa? Sin embargo, 
incluso si no se descubre la interfaz apropiada para la clase base y las funciones vir- 
tuales durante la creacion del programa, a menudo se descubriran mas tarde, incluso 
mucho mas tarde cuando se desee ampliar o se vaya a hacer funciones de manteni- 
miento en el programa. Esto no implica un error de analisis o de diseno; simplemente 
significa que no se conoda o no se podia conocer toda la informacion al principio. 
Debido a la fuerte modularizacion de C++, no es mucho problema que esto suceda 
porque los cambios que se hagan en una parte del sistema no tienden a propagarse 
a otras partes como sucede en C. 


15.5. Como implementa C++ la ligadura dinamica 

^Como funciona la ligadura dinamica? Todo el trabajo se realiza detras del felon 
gracias al compilador, que instala los mecanismos necesarios de la ligadura dinami¬ 
ca cuando se crean funciones virtuales. Debido a que los programadores se suelen 
beneficiar de la comprension del mecanismo de las funciones virtuales en C++, esta 
seccion mostrara la forma en que el compilador implementa este mecanismo. 

La palabra reservada virtual le dice al compilador que no debe realizar liga¬ 
dura estatica. Al contrario, debe instalar automaticamente todos los mecanismos ne¬ 
cesarios para realizar la ligadura dinamica. Esto significa que si se llama a play () 
para un objeto Brass a traves una direccion a la clase base Instrument, se usara la 
funcion apropiada. 

Para que funcione, el compilador tipico 2 crea una unica tabla (llamada VTABLE) 
por cada clase que contenga funciones virtuales. El compilador coloca las direc- 
ciones de las funciones virtuales de esa clase en concreto en la VTABLE. En cada 

2 Los compiladores pueden implementar el comportamiento virtual como quieran, pero el modo aqui 
descrito es una aproximacion casi universal. 
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clase con funciones virtuales el compilador coloca de forma secreta un puntero 11a- 
mado vpointer (de forma abreviada VPTR), que apunta a la VTABLE de ese objeto. 
Cuando se hace una llamada a una funcion virtual a traves de un puntero a la clase 
base (es decir, cuando se hace una llamada usando el polimorfismo), el compilador 
silenciosamente anade codigo para buscar el VPTR y asi conseguir la direccion de 
la funcion en la VTABLE, con lo que se llama a la funcion correcta y tiene lugar la 
ligadura dinamica. 

Todo esto - establecer la VTABLE para cada clase, inicializar el VPTR, insertar 
codigo para la llamada a la funcion virtual - sucede automaticamente sin que haya 
que preocuparse por ello. Con las funciones virtuales, se llama a la funcion apropiada 
de un objeto, incluso aunque el compilador no sepa el tipo exacto del objeto. 


15.5.1. Almacenando information de tipo 

Se puede ver que no hay almacenada informacion de tipo de forma explicita en 
ninguna de las clases. Pero los ejemplos anteriores, y la simple logica, dicen que debe 
existir algun tipo de informacion almacenada en los objetos; de otra forma el tipo no 
podria ser establecido en tiempo de ejecucion. Es verdad, pero la informacion de tipo 
esta oculta. Para verlo, aqui esta un ejemplo que muestra el tamano de las clases que 
usan funciones virtuales comparadas con aquellas que no las usan: 


//: C15:Sizes.cpp 

// Object sizes with/without virtual functions 

#include <iostream> 

using namespace std; 


class NoVirtual { 

int a; 
public: 

void x() const {} 

int i() const { return 1; } 

} ; 


class OneVirtual { 

int a; 
public: 

virtual void x() const |} 
int i() const { return 1; } 

1 ; 


class TwoVirtuals { 

int a; 
public: 

virtual void x() const {} 

virtual int i() const { return 1; } 

} ; 


int main() { 

cout << "int: " << sizeof(int) << endl; 
cout << "NoVirtual: " 

<< sizeof (NoVirtual) << endl; 
cout << "void* : " << sizeof(void* ) << endl; 
cout << "OneVirtual: " 

<< sizeof (OneVirtual) << endl; 
cout << "TwoVirtuals: " 
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<< sizeof (TwoVirtuals) << endl; 

} ///:- 


Sin funciones virtuales el tamano del objeto es exactamente el que se espera: el 
tamano de un linico ’ int. Con una unica funcion virtual en OneVirtual, el tamano 
del objeto es el tamano de NoVirtual mas el tamano de un puntero a void. Lo que 
implica que el compilador anade un unico puntero (el VPTR) en la estructura si se 
tienen una o mas funciones virtuales. No hay diferencia de tamano entre OneVirt¬ 
ual y TwoVirtuals. Esto es porque el VPTR apunta a una tabla con direcciones de 
funciones. Se necesita solo una tabla porque todas las direcciones de las funciones 
virtuales estan contenidas en esta tabla. 

Este ejemplo requiere como mmimo un miembro de datos. Si no hubiera miem- 
bros de datos, el compilador de C++ hubiera forzado a los objetos a ser de tamano no 
nulo porque cada objeto debe tener direcciones distintas Qse imagina como indexar 
un array de objetos de tamano nulo?). Por esto se inserta en el objeto un miembro 
"falso” ya que de otra forma tendrla un tamano nulo. Cuando se inserta la informa- 
cion de tipo gracias a la palabra reservada virtual, esta ocupa el lugar del miembro 
"falso". Intente comentar el int a en todas las clases del ejemplo anterior para com- 
probarlo. 


15.5.2. Pintar funciones virtuales 

Para entender exactamente que esta pasando cuando se usan funciones virtuales, 
es util ver la actividad que hay detras del telon. Aqul se muestra el array de punteros 

A[] in Instrument! . cpp: 


VTABLEs: 



Figura 15.1: Funciones virtuales 


El array de punteros a Instruments no tiene informacion espedfica de tipo; 
cada uno de ellos apunta a un objeto de tipo Instrument. Wind, Percussion, S- 

3 Algunos compiladores pueden aumentar el tamano pero seria raro. 
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tringed, y Brass encajan en esta categoria porque derivan de Instrument (esto 
hace que tengan la misma interfaz de Instrument, y puedan responder a los mis- 
mos mensajes), lo que implica que sus direcciones pueden ser metidas en el array Sin 
embargo, el compilador no sabe que sean otra cosa que objetos de tipo Instrume¬ 
nt, por lo que normalmente llamara a las versiones de las funciones que esten en la 
clase base. Pero en este caso, todas las funciones han sido declaradas con la palabra 
reservada virtual, por lo que ocurre algo diferente. Cada vez que se crea una clase 
que contiene funciones virtuales, o se deriva de una clase que contiene funciones vir¬ 
tuales, el compilador crea para cada clase una unica VTABLE, que se puede ver a la 
derecha en el diagrama. En esta tabla se colocan las direcciones de todas las funcio¬ 
nes que son declaradas virtuales en la clase o en la clase base. Si no se sobreescribe 
una funcion que ha sido declarada como virtual, el compilador usa la direccion de la 
version que se encuentra en la clase base (esto se puede ver en la entrada ad just a 
de la VTABLE de Brass). Ademas, se coloca el VPTR (descubierto en Sizes . cpp) 
en la clase. Hay un unico VPTR por cada objeto cuando se usa herencia simple como 
es el caso. El VPTR debe estar inicializado para que apunte a la direccion inicial de la 
VTABLE apropiada (esto sucede en el constructor que se vera mas tarde con mayor 
detalle). 

Una vez que el VPTR ha sido inicializado a la VTABLE apropiada, el objeto "sabe" 
de que tipo es. Pero este autoconocimiento no tiene valor a menos que sea usado en 
el momento en que se llama a la funcion virtual. 

Cuando se llama a una funcion virtual a traves de la clase base (la situacion que se 
da cuando el compilador no tiene toda la informacion necesaria para realizar la liga- 
dura estatica), ocurre algo especial. En vez de realizarse la tipica llamada a funcion, 
que en lenguaje ensamblador es simplemente un CALL a una direccion en concreto, 
el compilador genera codigo diferente para ejecutar la llamada a la funcion. Aqui 
se muestra a lo que se parece una llamada a adjust () para un objeto Brass, si se 
hace a traves de un puntero a Instrument (una referencia a Instrument produce 
el mismo efecto): 


puntero a VTABLE de Brass 



Figura 15.2: Tabla de punteros virtuales 


El compilador empieza con el puntero a Instrument, que apunta a la direccion 
inicial del objeto. Todos los objetos Instrument o los objetos derivados de Instr¬ 
ument tienen su VPTR en el mismo lugar (a menudo al principio del objeto), de tal 
forma que el compilador puede conseguir el VPTR del objeto. El VPTR apunta a la 
la direccion inicial de VTABLE. Todas las direcciones de funciones de las VTABLE 
estan dispuestas en el mismo orden, a pesar del tipo especifico del objeto. play () es 
el primero, what () es el segundo y adjust () es el tercero. El compilador sabe que 
a pesar del tipo especifico del objeto, la funcion ad just () se encuentra localizada en 
VPTR+2. Debido a esto, en vez de decir, "Llama a la funcion en la direccion absoluta 
Instrument: : adjust () (ligadura estatica y accion equivocada), se genera codigo 
que dice "Llama a la funcion que se encuentre en VPTR+2”. Como la busqueda del 
VPTR y la determinacion de la direccion de la funcion actual ocurre en tiempo de 
ejecucion, se consigue la deseada ligadura dinamica. Se envia un mensaje al objeto. 
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y el objeto se figura que debe hacer con el. 


15.5.3. Detras del telon 

Puede ser util ver el codigo ensamblador que se genera con la llamada a una 
funcion virtual, para poder ver como funciona la ligadura dinamica. Aqui esta la 
salida de un compilador a la llamada 

i.adjust (1); 

dentro de la funcion f (Instruments i): 

push 1 
push si 

mov bx, word ptr [si] 
call word ptr [bx+4] 
add sp, 4 

Los argumentos de una llamada a una funcion C++, como los de a una funcion C, 
son colocados en la pila de derecha a izquierda (este orden es necesario para poder 
soportar las listas de argumentos variables de C), por lo que el argumento 1 se pone 
al principio en la pila. En este punto en la funcion, el registro si (que es parte de 
la arquitectura del procesador Intel™ X86) contiene la direccion de i. Tambien se 
introduce en la pila porque es la direccion de comienzo del objeto de interes. Hay 
que recordar que la direccion del comienzo del objeto corresponde al valor de th¬ 
is^ this es introducido en la pila de manera oculta antes de cualquier llamada 
a funcion, por lo que la funcion miembro sabe sobre que objeto en concreto esta 
trabajando. Debido a esto se vera siempre uno mas que el numero de argumentos 
introducidos en la pila antes de una llamada a una funcion miembro (excepto para 
las funciones miembro static, que no tienen this). 

Ahora se puede ejecutar la llamada a la funcion virtual. Primero hay que producir 
el VPTR para poder encontrar la VTABLE. Para el compilador el VPTR se inserta al 
principio del objeto, por lo que el contenido de this corresponde al VPTR. La linea 

mov bx, word ptr [si] 

busca la direccion (word) a la que apunta si, que es el VPTR y la coloca dentro 
del registro bx. 

El VPTR contenido en bx apunta a la direccion inicial de la VTABLE, pero el pun- 
tero de la funcion a llamar no se encuentra en la posicion cero de la VTABLE, si no 
en la segunda posicion (debido a que es la tercera funcion en la lista). Debido al mo- 
delo de memoria cada puntero a funcion ocupa dos bytes, por lo que el compilador 
suma cuatro al VPTR para calcular donde esta la direccion de la funcion apropiada. 
Hay que hacer notar que este es un valor constante establecido en tiempo de com- 
pilacion, por lo que lo unico que ocurre es que el puntero a funcion que esta en la 
posicion dos apunta a adjust (). Afortunadamente, el compilador se encarga de 
todo y se asegura de que todos los punteros a funciones en todas las VTABLEs de 
una jerarquia particular se creen con el mismo orden, a pesar del orden en que se 
hayan sobreescrito las funciones en las clases derivadas. 

Una vez se ha calculado en la VTABLE la direccion del puntero apropiado, se 
llama a la funcion a la que apunta el puntero. Esto es, se busca la direccion y se llama 
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de una sola vez con la sentencia: 

call word ptr [bx+4] 


Finalmente, se retrocede el puntero de la pila para limpiar los argumentos que se 
pusieron antes de la llamada. En codigo ensamblador de C y de C++ se ve a menudo 
la instruction para limpiar la lista de argumentos pero puede variar dependiendo 
del procesador o de la implementation del compilador. 


15.5.4. Instalar el vpointer 

Debido a que el VPTR determina el comportamiento virtual de las funciones en 
un objeto, es critico que el VPTR siempre este apuntando a la VTABLE apropiada. 
No tendria sentido hacer una llamada a una funcion virtual antes de que este inicia- 
lizado apropiadamente a su correspondiente VTABLE. Por supuesto, el lugar donde 
se puede garantizar esta initialization es en el constructor, pero ninguno de los ejem- 
plos Instrument tiene constructor. 

Aqui es donde la creation del constructor por defecto es esencial. En los ejemplos 
Instrument, el compilador crea un constructor por defecto que no hace nada mas 
que inicializar el VPTR. Este constructor es, obviamente, llamado autormaticamente 
por todos los objetos Instrument antes de que se pueda hacer nada con ellos, lo 
que asegura el buen comportamiento con las llamadas a funciones virtuales. 

Las implicaciones de la initialization automatica del VPTR dentro de un cons¬ 
tructor se discute en un section posterior. 


15.5.5. Los objetos son diferentes 

Es importante darse cuenta de que el upcasting solo maneja direcciones. Si el 
compilador tiene un objeto, sabe su tipo concreto y ademas (en C++) no se usara 
la ligadura dinamica para ninguna de las llamadas a funciones - o como minimo el 
compilador no necesitard usar la ligadura dinamica. Por cuestiones de eficiencia, la 
mayoria de los compiladores usaran la ligadura estatica cuando esten haciendo una 
llamada a una funcion virtual de un objeto porque saben su tipo concreto. Aqui hay 
un ejemplo: 

//: C15:Early.cpp 

// Early binding & virtual functions 

#include <iostream> 

#include <string> 
using namespace std; 

class Pet { 
public: 

virtual string speak() const { return } 

} ; 


class Dog : public Pet { 
public: 

string speak() const { return "Bark!"; } 

} ; 


int main () { 
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Dog ralph; 

Pet* pi = Sralph; 

Pet& p2 = ralph; 

Pet p3; 

// Late binding for both: 
cout << "pl->speak() = " << pi 
cout << "p2.speak() = " << p2. 
// Early binding (probably): 
cout << "p3.speak() = " << p3. 


->speak 
speak () 

speak () 


() <<endl; 
<< endl; 

<< endl; 


} ///:- 


En pl->speak () y en p2 . speak (), se usan direcciones, lo que significa que 
la information es incompleta: pi y p2 pueden representar la direccion de una Pet 
o algo que derivee de una Pet, por lo que el debe ser usado el mecanismo virtual. 
Cuando se llama a p3.speak no existe ambigiiedad. El compilador conoce el ti- 
po exacto del objeto, lo que hace imposible que sea un objeto derivado de Pet - es 
exactamente una Pet. Por esto, probablemente se use la ligadura estatica. Sin embar¬ 
go, si el compilador no quiere trabajar mucho, puede usar la ligadura dinamica y el 
comportamiento sera el mismo. 


15.6. ^Por que funciones virtuales? 

A estas alturas usted se puede hacer una pregunta: "Si esta tecnica es tan impor- 
tante, y si se ejecuta la funcion correcta todo el tiempo, ^por que es una option? ^por 
que es necesario conocerla?" 

Es una buena pregunta, y la respuesta se debe a la filosofia fudamental de C++: 
"Debido a que no es tan eficiente”. Se puede ver en el codigo en lenguaje ensamblador 
que se generan, en vez de un simple CALL a una direccion absoluta, dos instruccio- 
nes ensamblador necesarias para preparar la llamada a funcion. Esto requiere mas 
codigo y tiempo de ejecucion. 

Algunos lenguajes orientado a objetos han decidido que la aproximacion a la li¬ 
gadura dinamica es intrmseca a la programacion orientada a objetos, que siempre 
debe tener lugar, que no puede ser opcional, y que el usuario no tiene por que co- 
nocerlo. Esta es una decision de diseno cuando se crea un lenguaje, y este camino 
particular es adecuado para varios lenguajes 4 . Sin embargo, C++ tiene una tara por 
venir de C, donde la eficiencia es critica. Despues de todo, C fue creado para sustituir 
al lenguaje ensamblador para la implementation de un sistema operativo (haciendo 
a este sistema operativo - Unix - mucho mas portable que sus antecesores). Y una 
de las principales razones para la invention de C++ fue hacer mas eficientes a los 
programadores de C 5 . Y la primera pregunta cuando un programador de C se pa- 
sa a C++ es, "^Como me afectara el cambio en velocidad y tamano? Si la respuesta 
fuera, "Todo es magnifico excepto en las llamadas a funciones donde siempre tendra 
un pequena sobrecarga extra”, mucha gente se hubiera aguantado con C antes que 
hacer el cambio a C++. Ademas las funciones inline no serian posibles, porque las 
funciones virtuales deben tener una direccion para meter en la VTABLE. Por lo tan- 
to las funciones virtuales son opcionales, y por defecto el lenguaje no es virtual, 
porque es la configuration mas eficiente. Stroustrup expuso que su linea de trabajo 

4 Smalltalk, Java y Python, por ejemplo, usan esta aproximacion con gran exito. 

3 En los laboratories Bell, donde se invento C, hay un monton de programadores de C. Hacerlos mas 
eficientes, aunque sea solo un poco, ahorra a la compania muchos millones. 
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era, "Si no lo usa, no lo pague". 

Ademas la palabra reservada virtual permite afinar el rendimiento. Cuando se 
disenan las clases, sin embargo, no hay que preocuparse por afinarlas. Si va a usar 
el polimorfismo, uselo en todos los sitios. Solo es necesario buscar funciones que se 
puedan hacer no virtuales cuando se este buscando modos de acelerar el codigo (y 
normalmente hay mucho mas que ganar en otras areas - una buena idea es intentar 
adivinar donde se encuentran los cuellos de botella). 

Como anecdota la evidencia sugiere que el tamano y la velocidad de C++ sufren 
un impacto del 10 por ciento con respecto a C, y a menudo estan mucho mas cerca 
de ser parejos. Ademas otra razon es que se puede disehar un programa en C++ mas 
rapido y mas pequeno que como serf a en C. 


15.7. Clases base abstractas y funciones virtuales 
puras 

A menudo en el diseno, se quiere la clase base para presentar solo una interfaz 
para sus clases derivadas. Esto es, se puede querer que nadie pueda crear un objeto 
de la clase base y que esta sirva unicamente para hacer un upcast hacia ella, y poder 
tener una interfaz. Se consigue haciendo a la clase abstract (abstracta), poniendo co¬ 
mo minimo una funcion virtual pura. Se puede reconocer a una funcion virtual pura 
porque usa la palabra reservada virtual y es seguida por =0. Si alguien intenta 
hacer un objeto de una clase abstracta, el compilador lo impide. Esta es una utilidad 
que fuerza a un diseno en concreto. 

Cuando se hereda una clase abstracta, hay que implementar todas las funciones 
virtuales, o la clase que hereda se convierte en una nueva clase abstracta. Crear una 
funcion virtual pura permite poner una fucion miembro en una interfaz sin forzar a 
proveer un cuerpo con codigo sin significado para esa funcion miembro. A1 mismo 
tiempo, una funcion virtual fuerza a las clases que la hereden a que implemente una 
definicion para ellas. 

En todos los ejemplos de los intrumentos, las funciones en la clase base Instru¬ 
ment eran siempre funciones «tontas». Si esas funciones hubieran sido llamadas algo 
iba mal. Esto es porque la intencion de la clase Instrument es crear una interfaz 
comun para todas las clases que deriven de ella. 
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Figura 15.3: Clase abstracta 


La unica razon para establecer una interfaz comun es que despues se pueda ex- 
presar de forma diferente en cada subtipo. Se crea una forma basica que tiene lo que 
esta en comun con todas las clases derivadas y nada mas. Por esto. Instrument es 
un candidato perfecto para ser una clase abstracta. Se crea una clase abstracta solo 
cuando se quiere manipular un conjunto de clases a traves de una interfaz comun, 
pero la interfaz comun no necesita tener una implementacion (o como mucho, no 
necesita una implementacion completa). 

Si se tiene un concepto como Instrument que funciona como clase abstracta, 
los objetos de esa clase casi nunca tendran sentido. Es decir. Instrument sirve sola- 
mente para expresar la interfaz, y no una implementacion particular, por lo que crear 
un objeto que sea unicamente un Instrument no tendra sentido, y probablemente 
se quiera prevenir al usuario de hacerlo. Se puede solucionar haciendo que todas 
las funciones virtuales en Instrument muestren mensajes de error, pero retrasa la 
aparicion de los errores al tiempo de ejecucion lo que obligara a un testeo exhausti¬ 
ve por parte del usuario. Es mucho mas productivo cazar el problema en tiempo de 
compilacion. 

Aqui esta la sintaxis usada para una funcion virtual pura: 

virtual void f() = 0; 


Haciendo esto, se indica al compilador que reserve un hueco para una funcion en 
la VTABLE, pero que no ponga una direccion en ese hueco. Incluso aunque solo una 
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funcion en una clase sea declarada como virtual pura, la VTABLE estara incompleta. 

Si la VTABLE de una clase esta incompleta, ^que se supone que debe hacer el 
compilador cuando alguien intente crear un objeto de esa clase? No seria seguro 
crear un objeto de esa clase abstracta, por lo que se obtendria un error de parte del 
compilador. Dicho de otra forma, el compilador garantiza la pureza de una clase 
abstracta. Hacer clases abstractas asegura que el programador cliente no puede hacer 
mal uso de ellas. 

Aqui tenemos Instrument4 . cpp modificado para usar funciones virtuales pu- 
ras. Debido a que la clase no tiene otra cosa que no sea funciones virtuales, se la 
llama clase abstracta pura: 

//: C15:Instruments.cpp 
// Pure abstract base classes 

#include <iostream> 

using namespace std; 

enum note { middleC, Csharp, Cflat }; // Etc. 

class Instrument { 

public: 

// Pure virtual functions: 

virtual void play(note) const = 0; 
virtual char* what() const = 0; 

// Assume this will modify the object: 

virtual void adjust (int) = 0; 

1 ; 

// Rest of the file is the same ... 

class Wind : public Instrument { 

public: 

void play (note) const { 

cout << "Wind::play" << endl; 

} 

char* what() const { return "Wind"; } 

void adjust (int) { } 

} ; 

class Percussion : public Instrument { 

public: 

void play (note) const { 

cout << "Percussion::play" << endl; 

} 

char* what() const { return "Percussion"; } 
void adjust (int) {} 

} ; 

class Stringed : public Instrument { 

public: 

void play (note) const { 

cout << "Stringed::play" << endl; 

} 

char* what() const { return "Stringed"; } 
void adjust (int) { } 

} ; 

class Brass : public Wind { 
public: 


450 
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void play (note) const { 

cout << "Brass::play" << endl; 

) 

char* what() const { return "Brass"; } 


class Woodwind : public Wind { 
public: 

void play (note) const { 

cout << "Woodwind::play" << endl; 

} 

char* what() const { return "Woodwind"; } 

} ; 


// Identical function from before: 
void tune (Instruments i) { 

// . . . 

i.play(middleC); 

} 

// New function: 

void f(Instruments i) { i.adjust(l); } 

int main() { 

Wind flute; 

Percussion drum; 

Stringed violin; 

Brass flugelhorn; 

Woodwind recorder; 
tune(flute); 
tune(drum); 
tune(violin); 
tune(flugelhorn); 
tune(recorder); 
f(flugelhorn); 

} ///:- 


Las funciones virtuales puras son utiles porque hacen explicita la abstraction de 
una clase e indican al usuario y al compilador como deben ser usadas. 

Hay que hacer notar que las funciones virtuales puras previenen a una clase abs- 
tracta de ser pasadas a una funcion por valor , lo que es una manera de prevenir el 
object slicing (que sera descrito de forma reducida). Convertir una clase en abstracta 
tambien permite garantizar que se use siempre un puntero o una referenda cuando 
se haga upcasting a esa clase. 

Solo porque una funcion virtual pura impida a la VTABLE estar completa no 
implica que no se quiera crear cuerpos de funcion para alguna de las otras funciones. 
A menudo se querra llamar a la version de la funcion que este en la clase base, incluso 
aunque esta sea virtual. Es una buena idea poner siempre el codigo comun tan cerca 
como sea posible de la raiz de la jerarquia. No solo ahorra codigo, si no que permite 
facilmente la propagation de cambios. 
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15.7.1. Definiciones virtuales puras 

Es posible proveer una definicion para una funcion virtual pura en la clase ba¬ 
se. Todavia implica decirle al compilador que no permita crear objetos de esa clase 
base abstracta, y que las funciones virtuales puras deben ser definidas en las clases 
derivadas para poder crear objetos. Sin embargo, puede haber un trozo de codigo en 
comun que se quiera llamar desde todas, o algunas de las clases derivadas en vez de 
estar duplicando codigo en todas las funciones. 

Este es un ejemplo de definicion de funciones virtuales. 

//: Cl5:PureVirtualDefinitions.cpp 
// Pure virtual base definitions 
#include <iostream> 

using namespace std; 

class Pet { 
public: 

virtual void speak () const = 0; 
virtual void eat ( ) const = 0; 

// Inline pure virtual definitions illegal: 

//! virtual void sleep () const = 0 {} 

} ; 

// OK, not defined inline 

void Pet::eat() const { 

cout << "Pet: :eat ()" << endl; 

} 


void Pet::speak() const { 

cout << "Pet::speak()" << endl; 

} 


class Dog : public Pet { 
public: 

// Use the common Pet code: 

void speak() const { Pet::speak (); } 

void eat() const { Pet::eat(); } 


int main () { 

Dog simba; // Richard's dog 
simba.speak(); 
simba.eat(); 

} ///:~ 


El hueco en la VTABLE de Pet todavia esta vaclo, pero tiene funciones a las que 
se puede llamar desde la clase derivada. 

Otra ventaja de esta caracterlstica es que perimite cambiar de una funcion virtual 
corriente a una virtual pura sin destrozar el codigo existente (es una forma para 
localizar clases que no sobreescriban a esa funcion virtual). 
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15.8. Herencia y la VTABLE 

Es facil imaginar lo que sucede cuando hay herencia y se sobreescriben algunas 
de las funciones virtuales. El compilador crea una nueva VTABLE para la nueva 
clase, e inserta las nuevas direcciones de las funciones usando ademas las direcciones 
de las funciones de la clase base para aquellas funciones virtuales que no se hayan 
sobreescrito. De un modo u otro, para todos los objetos que se puedan crear (es decir, 
aquellos que no tengan funciones virtuales puras) existe un conjunto completo de 
direcciones de funciones en la VTABLE, por lo que sera imposible hacer llamadas a 
una direccion que no este en la VTABLE (lo cual serf a desastroso). 

Pero <y]iie ocurre cuando se hereda y anade una nueva funcion virtual en la clase 
derivada? Aqui hay un sencillo ejemplo: 

//: C15:AddingVirtuals.cpp 
// Adding virtuals in derivation 

#include <iostream> 

#include <string> 
using namespace std; 

class Pet { 

string pname; 

public: 

Pet (const strings petName) : pname(petName) {} 
virtual string name() const { return pname; } 
virtual string speak() const { return } 

} ; 


class Dog : public Pet { 

string name; 

public: 

Dog (const strings petName) : Pet(petName) {} 
// New virtual function in the Dog class: 

virtual string sit() const { 
return Pet::name() + " sits"; 

} 

string speak() const { // Override 

return Pet::name() + " says 'Bark!'"; 


} ; 


int main () { 

Pet* p[] = {new Pet("generic"),new Dog("bob")}; 
cout << "p[0]->speak () = " 

<< p[0]->speak () << endl; 

cout << "p[1]->speak () = " 

<< p[1]->speak () << endl; 

//! cout << "p [1]->sit() = " 

//! << p[l]->sit() << endl; // Illegal 

} /// : ~ 


La clase Pet tiene dos funciones virtuales: speak () y name (). Dog anade una 
tercera funcion virtual llamada sit (), y sobreescribe el significado de speak (). Un 
diagrama ayuda a visualizar que esta ocurriendo. Se muestran las VTABLEs creadas 
por el compilador para Pet y Dog: 
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&Pet: :name 

€- 

_ . _s 

8<Pet: :name 

&Pet:: speak 



&Dog:: speak 

-s, x'* 

8tDog::sit 


Figura 15.4: Una nueva funcion virtual 


Hay que hacer notar, que el compilador mapea la direccion de speak () en exac- 
tamente el mismo lugar tanto en la VTABLE de Dog como en la de Pet. De igual 
forma, si una clase Pug heredara de Dog, su version de sit ( ) ocuparia su lugar en 
la VTABLE en la misma position que en Dog. Esto es debido a que el compilador 
genera un codigo que usa un simple desplazamiento numerico en la VTABLE para 
seleccionar una funcion virtual, como se vio con el ejemplo en lenguaje ensamblador. 
Sin importar el subtipo en concreto del objeto, su VTABLE esta colocada de la misma 
forma por lo que llamar a una funcion virtual se hara siempre del mismo modo. 

En este caso, sin embargo, el compilador esta trabajando solo con un puntero a 
un objeto de la clase base. La clase base tiene unicamente las funciones speak () 
y name ( ), por lo que son a las unicas funciones a las que el compilador permitira 
acceder. ^Como es posible saber que se esta trabajando con un objeto Dog si solo 
hay un puntero a un objeto de la clase base? El puntero podria apuntar a algun 
otro tipo, que no tenga una funcion sit () . En este punto, puede o no tener otra 
direccion a funcion en la VTABLE, pero en cualquiera de los casos, hacer una llamada 
a una funcion virtual de esa VTABLE no es lo que se desea hacer. De modo que el 
compilador hace su trabajo impidiendo hacer llamadas virtuales a funciones que 
solo existen en las clases derivadas. 

Hay algunos poco comunes casos en los cuales se sabe que el puntero actualmen- 
te apunta al objeto de una subclase especifica. Si se quiere hacer una llamada a una 
funcion que solo exista en esa subclase, entonces hay que hacer un molde (cast) del 
puntero. Se puede quitar el mensaje de error producido por el anterior programa 
con: 

((Dog *) p[1])->sit () 

Aqui, parece saberse que p [ 1 ] apunta a un objeto Dog, pero en general no se 
sabe. Si el problema consiste en averiguar el tipo exacto de todos los objetos, hay 
que volver a pensar porque posiblemente no se esten usando las funciones virtuales 
de forma apropiada. Sin embargo, hay algunas situaciones en las cuales el diseno 
funciona mejor (o no hay otra election) si se conoce el tipo exacto de todos los objetos, 
por ejemplo aquellos incluidos en un contenedor generico. Este es el problema de la 
run time type identification o RTTI (identification de tipos en tiempo de ejecucion). 

RTTI sirve para moldear un puntero de una clase base y "bajarlo" a un puntero de 
una clase derivada ("arriba" y "abajo”, en ingles "up" y "down" respectivamente, se 
refieren al tipico diagrama de clases, con la clase base arriba). Hacer el molde hacia 
arriba ( upcast ) funciona de forma automatica, sin coacciones, debido a que es com- 
pletamente seguro. Hacer el molde en sentido descendente (downcast) es inseguro 
porque no hay information en tiempo de compilation sobre los tipos actuates, por lo 
que hay que saber exactamente el tipo al que pertenece. Si se hace un molde al tipo 
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equivocado habra problemas. 

RTTI se describe posteriormente en este capitulo, y el Volumen 2 de este libro 
tiene un capitulo dedicado al tema. 


15.8.1. FIXME: Object slicing 

Existe una gran diferencia entre pasar una direction de un objeto a pasar el objeto 
por valor cuando se usa el polimorfismo. Todos los ejemplos que se han visto, y 
practicamente todos los ejemplos que se veran, se pasan por referenda y no por 
valor. Esto se debe a que todas las direcciones tienen el mismo tamano 6 , por lo que 
pasar la direction de un tipo derivado (que normalmente sera un objeto mas grande) 
es lo mismo que pasar la direction de un objeto del tipo base (que es normalmente 
mas pequeno). Como se explico anteriormente, este es el objetivo cuando se usa el 
polimorfismo - el codigo que maneja un tipo base puede, tambien manejar objetos 
derivados de forma transparente 

Si se hace un upcast de un objeto en vez de usar un puntero o una referenda, pa- 
sara algo que puede resultar sorprendente: el objeto es "truncado”, recortado, hasta 
que lo que quede sea un subobjeto que corresponda al tipo destino del molde. En 
el siguiente ejemplo se puede ver que ocurre cuando un objeto es truncado ( object 
slicing ): 

//: C15:0bjectSlicing.cpp 

#include <iostream> 

#include <string> 
using namespace std; 

class Pet { 

string pname; 

public: 

Pet (const strings name) : pname(name) {} 
virtual string name() const { return pname; } 
virtual string description() const { 
return "This is " + pname; 

} 

} ; 


class Dog : public Pet { 

string favoriteActivity; 

public: 

Dog (const strings name, const strings activity) 
: Pet(name), favoriteActivity(activity) {} 
string description() const { 

return Pet::name() + " likes to " + 
favoriteActivity; 

} 

} ; 


void describe(Pet p) { // Slices the object 
cout << p.description() << endl; 

1 


6 Actualmente, no todos los punteros tienen el mismo tamano en todos las maquinas. Sin embargo, 
en el contexto de esta discusion se pueden considerar iguales. 
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int main () { 

Pet p("Alfred" ) ; 

Dog d("Fluffy", "sleep"); 
describe(p); 
describe(d); 

} ///:- 


La funcion describe () recibe un objeto de tipo Pet por valor. Despues llama a 
la funcion virtual description () del objeto Pet. En el main (), se puede esperar 
que la primera llamada produzca "This is Alfred", y que la segunda produzca "Fluffy 
likes to sleep". De hecho, ambas usan la version description () de la clase base. 

En esteprograma estan sucediendo dos cosas. Primero, debido a que describe- 
() acepta un objeto Pet (en vez de un puntero o una referenda), cualquier llamada 
a describe () creara un objeto del tamano de Pet que sera puesto en la pila y 
posteriormente limpiado cuando acabe la llamada. Esto significa que si se pasa a d- 
escribe () un objeto de una clase heredada de Pet, el compilador lo acepta, pero 
copia unicamente el fragmento del objeto que corresponda a una Pet. Se deshecha 
el fragmento derivado del objeto: 


Before Slice After Slice 



Figura 15.5: Object slicing 


Ahora queda la cuestion de la llamada a la funcion virtual. Dog: : descript¬ 
ion () hace uso de trozos de Pet (que todavia existe) y de Dog, jel cual no existe 
porque fue truncado!. Entonces, ,;Que ocurre cuando se llama a la funcion virtual? 

El desastre es evitado porque el objeto es pasado por valor. Debido a esto, el com¬ 
pilador conoce el tipo exacto del objeto porque el objeto derivado ha sido forzado a 
transformarse en un objeto de la clase base. Cuando se pasa por valor, se usa el cons¬ 
tructor de copia del objeto Pet, que se encarga de inicializar el VPTR a la VTABLE 
de Pet y copia solo las partes del objeto que correspondan a Pet. En el ejemplo no 
hay un constructor de copia explicito por lo que el compilador genera uno. Quitando 
interpretaciones, el objeto se convierte realmente en una Pet durante el truncado. 

El Object Slicing quita parte del objeto existente y se copia en un nuevo objeto, 
en vez de simplemente cambiar el significado de una direccion cuando se usa un 
puntero o una referenda. Debido a esto, el upcasting a un objeto no se usa a menudo; 
de hecho, normalmente, es algo a controlar y prevenir. Hay que resaltar que en este 
ejemplo, si description () fuera una funcion virtual pura en la clase base (lo cual 
es bastante razonable debido a que realmente no hace nada en la clase base), entonces 
el compilador impedira el object slicing debido a que no se puede "crear" un objeto 
de la clase base (que al fin y al cabo es lo que sucede cuando se hace un upcast 
por valor), esto podria ser el valor mas importante de las funciones virtuales puras: 
prevenir el object slicing generando un error en tiempo de compilacion si alguien lo 
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intenta hacer. 


15.9. Sobrecargar y redefinir 

En el capitulo 14 se vio que redefinir una funcion sobrecargada en la funcion base 
oculta todas las otras versiones de esa funcion. Cuando se involucra a las funciones 
virtuales el comportamiento es un poco diferente. Consideremos una version modi- 
ficada del ejemplo NameHiding. cpp del capitulo 14: 

//: C15 :NameHiding2.cpp 

// Virtual functions restrict overloading 

#include <iostream> 

#include <string> 
using namespace std; 

class Base { 
public: 

virtual int f() const { 

cout << "Base::f ()\n"; 

return 1; 

} 

virtual void f (string) const {} 
virtual void g() const {} 

} ; 


class Derivedl : public Base { 
public: 

void g() const {} 

1 ; 


class Derived2 : public Base { 
public: 

// Overriding a virtual function: 

int f() const { 

cout << "Derived2::f()\n"; 

return 2; 


} ; 


class Derived3 : public Base { 
public: 

// Cannot change return type: 

//! void f() const{ cout << "Derived3::f()\n";} 


class Derived4 : public Base { 
public: 

// Change argument list: 

int f(int) const { 

cout << "Derived4::f()\n"; 

return 4; 


} ; 


int main () { 

string s("hello"); 
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Derivedl dl; 
int x = dl. f () ; 
dl.f (s) ; 

Derived2 d2; 
x = d2.f(); 

//! d2.f(s); // string version hidden 

Derived4 d4; 
x = d4.f(1); 

//! x=d4.f(); // f() version hidden 

//! d4.f(s); // string version hidden 

Bases br = d4; // Upcast 
//! br.f(l); // Derived version unavailable 
br.f(); // Base version available 
br.f(s); // Base version abailable 
} ///:~ 


La primera cosa a resaltar es que en Derived3, el compilador no permitira cam- 
biar el tipo de retorno de una funcion sobreescrita (lo permitiria si f () no fuera vir¬ 
tual). esta es una restriction importante porque el compilador debe garantizar que 
se pueda llamar de forma "polimorfica" a la funcion a traves de la clase base, y si la 
clase base esta esperando que f () devuelva un int, entonces la version de f () de la 
clase derivada debe mantener ese compromiso o si no algo fallara. 

La regia que se enseno en el capitulo 14 todavia funciona: si se sobreescribe una 
de las funciones miembro sobrecargadas de la clase base, las otras versiones sobre- 
cargadas estaran ocultas en la clase derivada. En el main () el codigo de Derived4 
muestra lo que ocurre incluso si la nueva version de f () no esta actualmente sobre- 
escribiendo una funcion virtual existente de la interfaz - ambas versiones de f () en 
la clase base estan ocultas por f ( int ). Sin embargo, si se hace un upcast de d4 a B- 
ase, entonces unicamente las versiones de la clase base estaran disponibles (porque 
es el compromiso de la clase base) y la version de la clase derivada no esta disponible 
(debido a que no esta especificada en la clase base). 


15.9.1. Tipo de retorno variante 

La clase Derived3 de arriba viene a sugerir que no se puede modificar el tipo 
de retorno de una funcion virtual cuando es sobreescrita. En general es verdad, pero 
hay un caso especial en el que se puede modificar ligeramente el tipo de retorno. Si 
se esta devolviendo un puntero o una referencia a una clase base, entonces la version 
sobreescrita de la funcion puede devolver un puntero o una referencia a una clase 
derivada. Por ejemplo: 

//: C15:VariantReturn.cpp 

// Returning a pointer or reference to a derived 
// type during ovverriding 

#include <iostream> 

#include <string> 
using namespace std; 

class PetFood { 
public: 

virtual string foodTypeO const = 0; 

}; 



© 


© 


© 
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class Pet { 
public: 

virtual string type() const = 0; 
virtual PetFood* eats () = 0; 


class Bird : public Pet { 
public: 

string type () const { return "Bird"; } 
class BirdFood : public PetFood { 
public: 

string foodTypeO const { 

return "Bird food"; 

} 


// Upcast to base type: 

PetFood* eats() { return &bf; } 

private: 

BirdFood bf; 


class Cat : public Pet { 
public: 

string type () const { return "Cat"; } 
class CatFood : public PetFood { 
public: 

string foodTypeO const { return "Birds"; } 

} ; 

// Return exact type instead: 

CatFood* eats () { return &cf; } 

private: 

CatFood cf; 


int main() { 

Bird b; 

Cat c; 

Pet* p[] = { &b, &c, }; 

for(int i = 0; i < sizeof p / sizeof *p; i++) 
cout << p[i]->type() << " eats " 

<< p[i]->eats()->foodType() << endl; 

// Can return the exact type: 

Cat::CatFood* cf = c.eats(); 

Bird::BirdFood* bf; 

// Cannot return the exact type: 

//! bf = b.eats(); 

// Must downcast: 

bf = dynamic_cast<Bird ::BirdFood*>(b.eats() ) ; 

} ///:~ 


La funcion miembro Pet: : eats () devuelve un puntero a PetFood. En Bird, 
esta funcion miembro es sobreescrita exactamente como en la clase base, incluyendo 
el tipo de retorno. Esto es. Bird: : eats () hace un >upcast de BirdFood a PetFood 
en el retorno de la funcion. 

Pero en Cat, el tipo devuelto por eats () es un puntero a CatFood, que es un 
tipo derivado de PetFood. El hecho de que el tipo de retorno este heredado del tipo 


459 


© 


© 


© 
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de retorno la funcion de la clase base es la unica razon que hace que esto compile. De 
esta forma el acuerdo se cumple totalmente: eats () siempre devuelve un puntero 

a PetFood. 

Si se piensa de forma polimorfica lo anterior no parece necesario. <T’or que no 
simplemente se hacen upcast de todos los tipos retornados a PetFood* como lo hace 
Bird: : eat s () ? Normalmente esa es una buena solucion, pero al final del main () 
se puede ver la diferencia: Cat: : eat s ( ) puede devolver el tipo exacto de PetFoo- 
d, mientras que al valor retornado por Bird: : eat s () hay que hacerle un downcast 
al tipo exacto. 

Devolver el tipo exacto es un poco mas general y ademas no pierde la informa- 
cion especifica de tipo debida al upcast automatico. Sin embargo, devolver un tipo de 
la clase base generalmente resuelve el problema por lo que esto es una caracteristica 
bastante especifica. 


15.10. funciones virtuales y constructores 

Cuando se crea un objeto que contiene funciones virtuales, su VPTR debe ser ini- 
cializado para apuntar a la correcta VTABLE. Esto debe ser hecho antes de que exista 
la oportunidad de llamar a una funcion virtual. Como se puede adivinar, debido a 
que el constructor tiene el trabajo de traer a la existencia al objeto, tambien sera traba- 
jo del constructor inicializar el VPTR. El compilador de forma secreta anade codigo 
al principio del constructor para inicializar el VPTR. Y como se describe en el capi¬ 
tulo 14, si no se crea un constructor de una clase de forma explicita, el compilador 
genera uno de forma automatica. Si la clase tiene funciones virtuales, el construc¬ 
tor incluira el codigo apropidado para la inicializacion del VPTR. Esto tiene varias 
consecuencias. 

La primera concierne a la eficiencia. La razon de que existan funciones inli¬ 
ne es reducir la sobrecarga que produce llamar a funciones pequenas. Si C++ no 
proporciona funciones inline, el preprocesador debe ser usado para crear estas 
"macros". Sin embargo, el preprocesador no tiene los conceptos de accesos o clases, 
y ademas no puede ser usado para crear macros con funciones miembro. Ademas, 
con los constructores que deben tener codigo oculto insertado por el compilador, una 
macro del preprocesador no funcionaria del todo. 

Hay que estar precavidos cuando se esten buscando agujeros de eficiencia porque 
el compilador esta insertando codigo oculto en los constructores. No solo hay que 
inicializar el VPTR, tambien hay que comprobar el valor de this (en caso de que el 
operador new devuelva cero), y llamar al constructor de la clase base. Todo junto, este 
codigo puede tener cierto impacto cuando se pensaba que era una simple funcion 
inline. En particular, el tamaho del constructor puede aplastar al ahorro que se 
consigue al reducir la sobrecarga en las llamadas. Si se hacen un monton de llamadas 
a constructores inline, el tamaho del codigo puede crecer sin ningun beneficio en la 
velocidad. 

Cuando este afinando el codigo recuerde considerar el quitar los constructores en 
linea. 


15.10.1. Orden de las llamadas a los constructores 

La segunda faceta interesante de los constructores y las funciones virtuales tie¬ 
ne que ver con el orden de las llamadas a los constructores y el modo en que las 
llamadas virtuales se hacen dentro de los constructores. 
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Todos los constructores de la clase base son siempre llamados en el constructor de 
una clase heredada. Esto tiene sentido porque el constructor tiene un trabajo especial: 
ver que el objeto esta construido de forma apropiada. Una clase derivada solo tiene 
acceso a sus propios miembros, y no a los de la clase base, unicamente el constructor 
de la clase base puede inicializar de forma adecuada a sus propios elementos. Por 
lo tanto es esencial que se llame a todos los constructores; de otra forma el objeto 
no estara construido de forma adecuada. Esto es por lo que el compilador obliga a 
hacer una llamada por cada trozo en una clase derivada. Se llamara al constructor 
por defecto si no se hace una llamada explfcita a un constructor de la clase base. Si 
no existe constructor por defecto, el compilador lo creara. 

El orden de las llamadas al constructor es importante. Cuando se hereda, se sabe 
todo sobre la clase base y se puede acceder a todos los miembros publicos y protegi- 
dos (public y protected) de la clase base, esto significa que se puede asumir que 
todos los miembros de la clase base son validos cuando se esta en la clase derivada. 
En una funcion miembro normal, la construction ya ha ocurrido, por lo que todos 
los miembros de todas las partes del objeto ya han sido construidos. Dentro del cons¬ 
tructor, sin embargo, hay que asumir que todos los miembros que se usen han sido 
construidos. La unica manera de garantizarlo es llamando primero al constructor de 
la clase base. Entonces cuando se este en el constructor de la clase derivada, todos los 
miembros a los que se pueda acceder en la clase base han sido inicializados. "Saber 
que todos los miembros son validos" dentro del constructor es tambien la razon por 
la que, dentro de lo posible, se debe inicializar todos los objetos miembros (es decir, 
los objetos puestos en la clase mediante composition). Si se sigue esta practica, se 
puede asumir que todos los miembros de la clase base y los miembros objetos del 
objeto actual han sido inicializados. 


15.10.2. Comportamiento de las funciones virtuales dentro 
de los constructores 

La jerarquia de las llamadas a los constructores plantea un interesante dilema. 
^Que ocurre si se esta dentro de un constructor y se llama a una funcion virtual? 
Dentro de una funcion miembro ordinaria se puede imaginar que ocurrira - la lla¬ 
mada virtual es resuelta en tiempo de ejecucion porque el objeto no puede conocer 
si la funcion miembro es de la clase en la que esta o es de una clase derivada. Por 
consistencia, se podria pensar que tambien es lo que deberia ocurrir dentro de los 
constructores. 

No es el caso. Si se llama a una funcion virtual dentro de un constructor, solo se 
usa la version local de la funcion. Es decir, el mecanismo virtual no funciona dentro 
del constructor. 

este comportamiento tiene sentido por dos motivos. Conceptualmente, el trabajo 
del constructor es dar al objeto una existencia. Dentro de cualquier constructor, el 
objeto puede ser formado solo parcialmente - se puede saber solo que los objetos 
de la clase base han sido inicializados, pero no se puede saber que clases heredan 
de esta. Una funcion virtual, sin embargo, se mueve "arriba" y "abajo” dentro de la 
jerarquia de herencia. Llama a una funcion de una clase derivada. Si se pudiera hacer 
esto dentro de un constructor, se estaria llamando a una funcion que debe manejar 
miembros que todavia no han sido inicializados, una receta segura para el desastre. 

El segundo motivo es mecanico. Cuando se llama a un constructor, una de las 
primeras cosas que hace es inicializar su VPTR. Sin embargo, solo puede saber que 
es del tipo "actual" - el tipo para el que se ha escrito el constructor. El codigo del 
constructor ignora completamente si el objeto esta en la base de otra clase. Cuando 
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el compilador genera codigo para ese constructor, se genera codigo para un construc¬ 
tor de esa clase, no para la clase base, ni para una clase derivada (debido a que una 
clase no puede saber quien la hereda). Por eso, el VPTR que use debe apuntar a la 
VTABLE de esa clase. El VPTR permanece inicializado a la VTABLE para el resto de 
vida del objeto a menos que no sea la ultima llamada al constructor. Si posteriormen- 
te se llama a un constructor de una clase derivada, este constructor pone el VPTR a 
su VTABLE, y as! hasta que el ultimo constructor termine. El estado del VPTR es de- 
terminado por el constructor que sea llamado en ultimo lugar. Otra razon por la que 
los constructores son llamados en orden desde la base al mas derivado. 

Pero mientras que toda esta serie de llamadas al constructor tiene lugar, cada 
constructor ha puesto el VPTR a su propia VTABLE. Si se usa el mecanismo virtual 
para llamar a funciones, producira solo una llamada a traves de su propia VTABLE, 
y no de la VTABLE del mas derivado (como deberia suceder despues de que todos 
los constructores hayan sido llamados). Ademas, muchos compiladores reconocen 
cuando se hace una llamada a una funcion virtual dentro de un constructor, y rea- 
lizan una ligadura estatica porque saben que la ligadura dinamica producira una 
llamada a una funcion local. En todo caso, no se conseguiran los resultados que se 
podian esperar inicialmente de la llamada a una funcion virtual dentro de un cons¬ 
tructor. 


15.10.3. Destructores y destructores virtuales 

No se puede usar la palabra reservada virtual con los constructores, pero los 
destructores pueden, y a menudo deben, ser virtuales. 

El constructor tiene el trabajo especial de iniciar un objeto poco a poco, primero 
llamando al constructor base y despues a los constructores derivados en el orden de 
la herencia. De manera similar, el destructor tiene otro trabajo especial: desmontar un 
objeto, el cual puede pertenecer a una jerarquia de clases. Para hacerlo, el compilador 
genera codigo que llama a todos los destructores, pero en el orden inverso al que 
son llamados en los constructores. Es decir, el constructor empieza en la clase mas 
derivada y termina en la clase base, esta es la opcion deseable y segura debido a que 
el destructor siempre sabe que los miembros de la clase base estan vivos y activos. 
Si se necesita llamar a una funcion miembro de la clase base dentro del destructor, 
sera seguro hacerlo. De esta forma, el destructor puede realizar su propio limpiado, 
y entonces llamar al siguiente destructor, el cual hara su propio limpiado, etc. Cada 
destructor sabe de que clase deriva, pero no cuales derivan de el. 

Hay que tener en cuenta que los constructores y los destructores son los unicos 
lugares donde tiene que funcionar esta jerarquia de llamadas (que es automatica- 
mente generada por el compilador). En el resto de las funciones, solo esa funcion, 
sea o no virtual, sera llamada (y no las versiones de la clase base). La unica forma 
para acceder a las versiones de la clase base de una funcion consiste en llamar de 
forma explicita a esa funciones. 

Normalmente, la accion del destructor es adecuada. Pero ^qiie ocurre si se quiere 
manipular un objeto a traves de un puntero a su clase base (es decir, manipular al ob¬ 
jeto a traves de su interfaz generica)? Este tipo de actividades es uno de los objetivos 
de la programacion orientada a objetos. El problema viene cuando se quiere hacer 
un delete (eliminar) de un puntero a un objeto que ha sido creado en el monton 
(: >heap ) con new. Si el puntero apunta a la clase base, el compilador solo puede co- 
nocer la version del destructor que se encuentre en la clase base durante el delete. 
^Suena familiar? Al fin y al cabo, es el mismo problema por las que fueron creadas 
las funciones virtuales en el caso general. Afortunadamente, las funciones virtuales 
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funcionan con los destructores como lo hacen para las otras funciones excepto los 
constructores. 

//: C15:VirtualDestructors.cpp 

// Behavior of virtual vs. non-virtual destructor 

#include <iostream> 

using namespace std; 

class Basel { 
public: 

-Basel () { cout << "-Basel()\n"; } 

} ; 


class Derivedl : public Basel { 
public: 

-Derivedl() { cout << "-Derivedl()\n"; } 

} ; 


class Base2 { 
public: 

virtual ~Base2() { cout << "~Base2()\n"; } 

} ; 

class Derived2 : public Base2 { 
public: 

~Derived2() { cout << "~Derived2()\n"; } 

} ; 


int main () { 

Basel* bp = new Derivedl; // Upcast 

delete bp; 

Base2* b2p = new Derived2; // Upcast 

delete b2p; 

} ///:~ 


Cuando se ejecuta el programa, se ve que delete bp solo llama al destructor 
de la clase base, mientras que delete b2p llama al destructor de la clase derivada 
seguido por el destructor de la clase base, que es el comportamiento que deseamos. 
Olvidar hacer virtual a un destructor es un error peligroso porque a menudo no 
afecta directamente al comportamiento del programa, pero puede introducir de for¬ 
ma oculta agujeros de memoria. Ademas, el hecho de que alguna destruction esta 
teniendo lugar puede enmascarar el problema. 

Es posible que el destructor sea virtual porque el objeto sabe de que tipo es (lo 
que no ocurre durante la construction del objeto). Una vez que el objeto ha sido 
construido, su VPTR es inicializado y se pueden usar las funciones virtuales. 


15.10.4. Destructores virtuales puros 

Mientras que los destructores virtuales puros son legales en el Standard C++, hay 
una restriction anadida cuando se usan: hay que proveer de un cuerpo de funcion a 
los destructores virtuales puros. Esto parece antinatural; ^Como puede una funcion 
virtual ser "pura" si necesita el cuerpo de una funcion? Pero si se tiene en cuenta que 
los constructores y los destructores son operaciones especiales tiene mas sentido, 
especialmente si se recuerda que todos los destructores en una jerarquia de clases 
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son llamados siempre. Si se quita la definicion de un destructor virtual puro, ^a que 
cuerpo de funcion se llamara durante la destruction? Por esto, es absolutamente 
necesario que el compilador y el enlazador requieran la existencia del cuerpo de una 
funcion para un destructor virtual puro. 

Si es puro, pero la funcion tiene cuerpo ^cual es su valor? La unica diferencia que 
se vera entre el destructor virtual puro y el no-puro es que el destructor virtual puro 
convierte a la clase base en abstracta, por lo que no se puede crear un objeto de la 
clase base (aunque esto tambien seria verdad si cualquier otra funcion miembro de 
esa clase base fuera virtual pur a). 

Sin embargo, las cosas son un poco confusas cuando se hereda una clase de otra 
que contenga un destructor puro virtual. A1 contrario que en el resto de las funciones 
virtuales puras, no es necesario dar una definicion de un destructor virtual puro en 
la clase derivada. El hecho de que el siguiente codigo compile es la prueba: 

//: C15:UnAbstract.cpp 
// Pure virtual destructors 
// seem to behave strangely 

class AbstractBase { 

public: 

virtual -AbstractBase() = 0; 

} ; 

AbstractBase::-AbstractBase() {} 

class Derived : public AbstractBase {}; 

// No overriding of destructor necessary? 

int raain() { Derived d; } ///:- 


Normalmente, una funcion virtual pura en una clase base causara que la clase de¬ 
rivada sea abstracta a menos que esa (y todas las demas funciones virtuales puras) 
tengan una definicion. Pero aqui, no parece ser el caso. Sin embargo, hay que recor- 
dar que el compilador crea automdticamente una definicion del destructor en todas las 
clases si no se crea una de forma explicita. Esto es lo que sucede aqui - el destructor 
de la clase base es sobreescrito de forma oculta, y una definicion es puesta por el 
compilador por lo que Derived no es abstracta. 

Esto nos brinda una cuestion interesante: ^Cual es el sentido de un destructor 
virtual puro? A1 contrario que con las funciones virtuales puras ordinarias en las 
que hay que dar el cuerpo de una funcion, en una clase derivada de otra con un 
destructor virtual puro, no se esta obligado a implementar el cuerpo de la funcion 
porque el compilador genera automaticamente el destructor. Entonces ^Cual es la 
diferencia entre un destructor virtual normal y un destructor virtual puro? 

La unica diferencia ocurre cuando se tiene una clase que solo tiene una funcion 
virtual pura: el destructor. En este caso, el unico efecto de la pureza del destructor 
es prevenir la instantiation de la clase base, pero si no existen otros destructores 
en las clase heredadas, el destructor virtual se ejecutara. Por esto, mientras que el 
ahadir un destructor virtual es esencial, el hecho de que sea puro o no lo sea no es 
tan importante. 

Cuando se ejecuta el siguiente ejemplo, se puede ver que se llama al cuerpo de la 
funcion virtual pura despues de la version que esta en la clase derivada, igual que 
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con cualquier otro destructor. 

//: C15:PureVirtualDestructors.cpp 
// Pure virtual destructors 
// require a function body 
#include <iostream> 

using namespace std; 

class Pet { 
public: 

virtual -Pet () = 0; 

} ; 

Pet::-Pet () { 

cout << "-Pet ()" << endl; 

} 


class Dog : public Pet { 
public: 

~Dog() { 

cout << "~DogO" << endl; 


} ; 


int main () { 

Pet* p = new Dog; // Upcast 
delete p; // Virtual destructor call 
} ///:- 


Como guia, cada vez que se tenga una funcion virtual en una clase, se deberia 
ana dir inmediatamente un destructor virtual (aunque no haga nada). De esta forma 
se evitan posteriores sorpresas. 


15.10.5. Mecanismo virtual en los destructores 

Hay algo que sucede durante la destruction que no se espera de manera intuiti- 
va. Si se esta dentro de una funcion miembro y se llama a una funcion virtual, esa 
funcion es ejecutada usando el mecanismo de la ligadura dinamica. Esto no es ver- 
dad con los destructores, virtuales o no. Dentro de un destructor, solo se llama a la 
funcion miembro "local"; el mecanismo virtual es ignorado. 

//: C15:VirtualsInDestructors.cpp 
// Virtual calls inside destructors 
#include <iostream> 

using namespace std; 

class Base { 
public: 

virtual -Based { 

cout << "Basel ()\n"; 
f 0 ; 

1 

virtual void f() { cout << "Base::f ()\n"; } 

}; 
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class Derived : public Base { 
public: 

-Derived!) { cout << "-Derived () \n" ; } 

void f() { cout << "Derived::f()\n"; } 


int main () { 

Base* bp = new Derived; // Upcast 

delete bp; 

} ///:- 


Durante la llamada al destructor virtual, no se llama a Derived: : f (), incluso 
aunque f () es virtual. 

IA que es debido esto? Supongamos que fuera usado el mecanismo virtual dentro 
del destructor. Entonces serla posible para la llamada virtual resolver una funcion 
que esta "lejana" (mas derivada) en la jerarqula de herencia que el destructor actual. 
Pero los destructores son llamados de "afuera a dentro" (desde el destructor mas 
derivado hacia el destructor de la clase base), por lo que la llamada actual a la funcion 
puede intentar acceder a fragmentos de un objeto que !ya ha sido destruido! En vez de 
eso, el compilador resuelve la llamada en tiempo de compilacion y llama solo a la 
version local de la funcion. Hay que resaltar que lo mismo es tambien verdad para el 
constructor (como se explico anteriormente), pero en el caso del constructor el tipo 
de informacion no estaba disponible, mientras que en el destructor la informacion 
esta ahi (es decir, el VPTR) pero no es accesible. 


15.10.6. Creadon una jerarqula basada en objetos 

Un asunto que ha aparecido de forma recurrente a lo largo de todo el libro cuan- 
do se usaban las clases Stack y Stash es el "problema de la propiedad". El "pro- 
pietario" se refiere a quien o al que sea responsable de llamar al delete de aquellos 
objetos que hayan sido creados dinamicamente (usando new). El problema cuando 
se usan contenedores es que es necesario ser lo suficientemente flexible para mane- 
jar distintos tipos de objetos. Para conseguirlo, los contenedores manejan punteros 
a void por lo que no pueden saber el tipo del objeto que estan manejando. Borrar 
un puntero a void no llama al destructor, por lo que el contenedor no puede ser 
responsable de borrar sus objetos. 

Una solucion fue presentada en el ejemplo Cl 4 : InheritStack . cpp, en el que 
Stack era heredado en una nueva clase que aceptaba y produda unicamente objetos 
string, por lo que se les podia borrar de manera adecuada. Era una buena solucion 
pero requerla heredar una nueva clase contenedera por cada tipo que se quisiera 
manejar en el contenedor. (Aunque suene un poco tedioso funciona bastante bien 
como se vera en el capitulo 16 cuando las plantillas o templates sean introducidos). 

El problema es que se quiere que el contenedor maneje mas de un tipo, pero 
solo se quieren usar punteros a void. Otra solucion es usar polimorfismo forzando 
a todos los objetos incluidos en el contenedor a ser heredados de la misma clase 
base. Es decir, el contenedor maneja los objetos de la clase base, y solo hay que usar 
funciones virtuales - en particular, se pueden llamar a destructores virtuales para 
solucionar el problema de pertenencia. 

Esta solucion usa lo que se conoce como "jerarqula de raiz unica" ( singly-rooted hie¬ 
rarchy) o "jerarqula basada en objetos” ( object-based hierarchy), siendo el ultimo nom- 
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bre debido a que la clase raiz de la jerarquia suele ser llamada "Objeto'. Ademas, el 
usar jerarquia de raiz unica, tiene como resultado otros beneficios: de hecho, cual- 
quier otro lenguaje orientado a objetos que no sea el C++ obliga a usar una jerarquia 
- cuando se crea una clase se hereda automaticamente de forma directa o indirecta de 
una clase base comun, una clase base que fue establecida por los creadores del len¬ 
guaje. En C++, se penso que forzar a tener una base clase comun crearia demasiada 
sobrecarga, por lo que se desestimo. Sin embargo, se puede elegir usar en nuestros 
proyectos una clase base comun, y esta materia sera tratada en el segundo volumen 
de este libro. 

Para solucionar el problema de pertenencia, se puede crear una clase base Ob¬ 
ject extremadamente simple, que solo tiene un destructor virtual. De esta forma 
Stack puede manejar objetos que hereden de Object: 

//: C15:OStack.h 

// Using a singly-rooted hierarchy 

#ifndef OSTACK_H 
#define OSTACK_H 

class Object { 
public: 

virtual -Object() = 0; 

} ; 

// Required definition: 
inline Object::-Object() {} 

class Stack { 
struct Link { 

Object* data; 

Link* next; 

Link(Object* dat, Link* nxt) : 
data(dat), next(nxt) {} 

}* head; 

public: 

Stack() : head(0) {} 

-Stack(){ 
while (head) 

delete pop(); 

} 

void push(Object* dat) { 

head = new Link(dat, head); 

} 

Object* peek() const { 

return head ? head->data : 0; 

} 

Object* pop () { 

if (head == 0) return 0; 

Object* result = head->data; 

Link* oldHead = head; 
head = head->next; 
delete oldHead; 
return result; 

} 

} ; 

#endif // OSTACK_H ///:- 
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Para simplificar las cosas se crea todo en el fichero cabecera, la definicion (re- 
querida) del destructor virtual puro es introducida en linea el el fichero cabecera, y 
pop () tambien esta en linea aunque podria ser considearado como demasiado largo 
para ser incluido asi. 

Los objetos Link (lista) ahora manejan punteros a Object en vez de punteros a 
void, y la Stack (pila) solo aceptara y devolvera punteros a Ob ject. Ahora Stack 
es mucho mas flexible, ya que puede manejar un monton de tipos diferentes pero 
ademas es capaz de destruira cualquier objeto dejado en la pila. La nueva limitacion 
(que sera finalmente eliminada cuando las plantillas se apliquen al problema en el 
capitulo 16) es que todo lo que se ponga en la pila debe ser heredado de Ob j e ct. Esto 
esta bien si se crea una clase desde la nada, pero /que pasa si se tiene una clase como 
stringyse quiere ser capaz de meterla en la pila? En este caso, la nueva clase debe 
ser al mismo tiempo un string y un Object, lo que significa que debe heredar de 
ambas clases. Esto se conoce como herencia multiple y es materia para un capitulo en- 
tero en el Volumen 2 de este libro (se puede bajar de www.BruceEckel.com). cuando 
se lea este capitulo, se vera que la herencia multiple genera un monton de comple- 
jidad, y que es una caracteristica que hay que usar con cuentagotas. Sin embargo, 
esta situacion es lo suficientemente simple como para no tener problemas al usar 
herencia multiple: 

//: C15:OStackTest.cpp 
//{T} OStackTest.cpp 

#include "OStack.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

// Use multiple inheritance. We want 
// both a string and an Object: 

class MyString: public string, public Object { 
public: 

-MyString() { 

cout << "deleting string: " << *this << endl; 

} 

MyString(string s) : string(s) {} 

} ; 

int main(int argc, char* argv[]) { 

requireArgs(argc, 1); // File name is argument 
ifstream in(argv[l]); 
assure(in, argv[lj); 

Stack textlines; 
string line; 

// Read file and store lines in the stack: 

while (getline(in, line)) 

textlines.push (new MyString(line)) ; 

// Pop some lines from the stack: 

MyString* s; 

for(int i = 0; i < 10; i++) { 

if ((s=(MyString*)textlines.pop())==0) break ; 
cout << *s << endl; 

delete s; 

} 

cout << "Letting the destructor do the rest:" 
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<< endl; 
} // / : ~ 


Aunque es similar a la version anterior del programa de pruebas de Stack, se 
puede ver que solo se han sacado 10 elementos de la pila, lo que implica que proba- 
blemente quede algun elemento. Como la pila ahora maneja Objects, el destructor 
puede limpiarlos de forma adecuada, como se puede ver en la salida del programa 
gracias a que los objetos My St ring muestran un mensaje cuando son destruidos. 

Crear contenedores que manejen Objects es una aproximacion razonable - si se 
tiene una jerarquia de raiz unica (debido al lenguaje o por algun requerimiento que 
obligue a que todas las clases hereden de Object). En este caso, esta garantizado 
que todo es un Ob ject y no es muy complicado usar contenedores. Sin embargo, en 
C++ no se puede esperar este comportamiento de todas las clases, por lo que se esta 
abocado a usar herencia multiple si se quiere usar esta aproximacion. Se vera en el 
capitulo 16 que las plantillas solucionan este problema de una forma mas simple y 
elegante. 


15.11. Sobrecarga de operadores 

Se pueden crear operadores virtuales de forma analoga a otras funciones miem- 
bro. Sin embargo implementar operadores virtuales se vuelve a menudo confuso 
porque se esta operando sobre dos objetos, ambos sin tipos conocidos. Esto suele ser 
el caso de los componentes matematicos (para los cuales se suele usar la sobrecar¬ 
ga de operadores). Por ejemplo, considere un sistema que usa matrices, vectores y 
valores escalares, todos ellos heredados de la clase Math: 

//: C15:OperatorPolymorphism.cpp 
// Polymorphism with overloaded operators 
#include <iostream> 

using namespace std; 

class Matrix; 
class Scalar; 
class Vector; 

class Math { 
public: 

virtual Maths operator* (Maths rv) = 0; 
virtual Maths multiply(Matrix*) = 0; 
virtual Maths multiply(Scalar*) = 0; 
virtual Maths multiply(Vector*) = 0; 
virtual ~Math() {} 

} ; 


class Matrix : public Math { 
public: 

Maths operator* (Maths rv) { 

return rv.multiply (this) ; // 2nd dispatch 

} 

Maths multiply(Matrix*) { 

cout << "Matrix * Matrix" << endl; 

return *this; 

} 
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Maths multiply(Scalar*) { 

cout << "Scalar * Matrix" << endl; 

return *this; 

} 

Maths multiply(Vector*) { 

cout << "Vector * Matrix" << endl; 

return *this; 



class Scalar : public Math { 
public: 

Maths operator* (Maths rv) { 

return rv.multiply (this) ; // 2nd dispatch 

} 

Maths multiply(Matrix*) { 

cout << "Matrix * Scalar" << endl; 

return *this; 

} 

Maths multiply(Scalar*) { 

cout << "Scalar * Scalar" << endl; 

return *this; 


Maths multiply(Vector*) { 

cout << "Vector * Scalar" << endl; 

return *this; 



class Vector : public Math { 
public: 

Maths operator* (Maths rv) { 

return rv.multiply (this) ; // 2nd dispatch 


Maths multiply(Matrix*) { 

cout << "Matrix * Vector" << endl; 

return *this; 

} 

Maths multiply(Scalar*) { 

cout << "Scalar * Vector" << endl; 

return *this; 

} 

Maths multiply(Vector*) { 

cout << "Vector * Vector" << endl; 

return *this; 



int main () { 

Matrix m; Vector v; Scalar s; 
Math* math[] = { Sm, Sv, Ss }; 
for(int i = 0; i < 3; i++) 
for (int j = 0; j<3; j++) { 

Maths ml = *math[i]; 

Maths m2 = *math[j]; 
ml * m2; 

} 


} ///:~ 
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Para simplificar solo se ha sobrecargado el operator 51 '. El objetivo es ser capaz de 
multiplicar dos objetos Math cualquiera y producir el resultado deseado - hay que 
darse cuenta que multiplicar una matriz por un vector es una operacion totalmente 
distinta a la de multiplicar un vector por una matriz. 

El problema es que, en el main (), la expresion ml * m2 contiene dos referencias 
Math, y son dos objetos de tipo desconocido. Una funcion virtual es solo capaz de 
hacer una unica llamada - es decir, determinar el tipo de un unico objeto. Para de- 
terminar ambos tipos en este ejemplo se usa una tecnica conocida como despachado 
multiple ( multiple dispatching), donde lo que parece ser una unica llamada a una fun¬ 
cion virtual se convierte en una segunda llamada a una funcion virtual. Cuando la 
segunda llamada se ha ejecutado, ya se han determinado ambos tipos de objetos y 
se puede ejecutar la actividad de forma correcta. En un principio no es transparante, 
pero despues de un rato mirando el codigo empieza a cobrar sentido. Esta materia es 
tratada con mas profundidad en el capitulo de los patrones de diseno en el Volumen 
2 que se puede bajar de >www.BruceEckel.com. 


15.12. Downcasting 

Como se puede adivinar, desde el momento que existe algo conocido como up¬ 
casting - mover en sentido ascendente por una jerarquia de herencia - debe existir el 
downcasting para mover en sentido descendente en una jerarquia. Pero el upcasting 
es sencillo porque al movernos en sentido ascendente en la jerarquia de clases siem- 
pre convergemos en clases mas generales. Es decir, cuando se hace un upcast siempre 
se esta en una clase claramente derivada de un ascendente (normalmente solo uno, 
excepto en el caso de herencia multiple) pero cuando se hace downcast hay normal¬ 
mente varias posibilidades a las que amoldarse. Mas concretamente, un Circulo es 
un tipo de Figura (que seria su upcast), pero si se intenta hacer un downcast de una 
Figura podria ser un Circulo, un Cuadrado, un Triangulo, etc. El problema 
es encontrar un modo seguro de hacer downcast (aunque es incluso mas importante 
preguntarse por que se esta usando downcasting en vez de usar el polimorfismo para 
que adivine automaticamente el tipo correcto. En el Volumen 2 de este libro se trata 
como evitar el doivncasting. 

C++ proporciona un moldeado explicito especial (introducido en el capitulo 3) 
llamado "moldeado dinamico" ( dynamic_cast) que es una operacion segura. Cuando 
se usa moldeado dinamico para intentar hacer un molde a un tipo en concreto, el valor 
de retorno sera un puntero al tipo deseado solo si el molde es adecuado y tiene exito, 
de otra forma devuelve cero para indicar que no es del tipo correcto. Aqui tenemos 
un ejemplo minimo: 


//: C15:DynamicCast.cpp 

#include <iostream> 

using namespace std; 


class Pet { 

public: 

virtual ~ 

class Dog : 

public 

Pet 

U; 

class Cat : 

public 

Pet 

U; 

int main() 

{ 



Pet* b = 

new Cat; 

// 

Upcast 

// Try to 

cast it 

to 

Dog* : 
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Dog* dl = dynamic_cast<Dog*>(b) ; 

// Try to cast it to Cat*: 

Cat* d2 = dynamic_cast<Cat*> (b) ; 
cout << "dl = " << (long)dl << endl; 
cout << "d2 = " << (long)d2 << endl; 
} ///:- 


Cuando se use moldeado dindmico, hay que trabajar con una jerarquia polimorfica 
real - con funciones virtuales - debido a que el modeado dindmico usa informacion 
almacenada en la VTABLE para determinar el tipo actual. Aqui, la clase base contiene 
un destructor virtual y esto es suficiente. En el main (), un puntero a Cat es elevado 
a Pet, y despues se hace un downcast tanto a puntero Dog como a puntero a C- 
at. Ambos punteros son imprimidos, y se puede observar que cuando se ejecuta 
el programa el downcast incorrecto produce el valor cero. Por supuesto somos los 
responsables de comprobar que el resultado del cast no es cero cada vez que se haga 
un downcast. Ademas no hay que asumir que el puntero sera exactamente el mismo, 
porque a veces se realizan ajustes de punteros durante el upcasting y el downcasting 
(en particular, con la herencia multiple). 

Un moldeado dindmico requiere un poco de sobrecarga extra en ejecucion; no mu- 
cha, pero si se esta haciendo mucho moldeado dindmico (en cuyo caso deberia ser 
cuestionado seriamente el diseno del programa) se convierte en un lastre en el ren- 
dimiento. En algunos casos se puede tener alguna informacion especial durante el 
downcasting que permita conocer el tipo que se esta manejando, con lo que la sobre¬ 
carga extra del modeado dindmico se vuelve innecesario, y se puede usar de manera 
alternativa un moldeado estdtico. Aqui se muestra como funciona: 

// : C15:StaticHierarchyNavigation.cpp 
// Navigating class hierarchies with static_cast 
#include <iostream> 

#include <typeinfo> 

using namespace std; 

class Shape { public: virtual -Shape() {}; }; 

class Circle : public Shape {}; 
class Square : public Shape {}; 
class Other {}; 

int main () { 

Circle c; 

Shape* s = &c; // Upcast: normal and OK 
// More explicit but unnecessary: 
s = static_cast<Shape*>(&c) ; 

// (Since upcasting is such a safe and common 
// operation, the cast becomes cluttering) 

Circle* cp = 0; 

Square* sp = 0; 

// Static Navigation of class hierarchies 
// requires extra type information: 

if(typeid(s) == typeid(cp)) // C++ RTTI 
cp = static_cast<Circle*>(s); 

if(typeid(s) == typeid(sp)) 

sp = static_cast<Square*>(s); 
if (cp != 0) 

cout << "It's a circle!" << endl; 
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if (sp != 0) 

cout << "It's a square!" << endl; 

// Static navigation is ONLY an efficiency hack; 
// dynamic_cast is always safer. However: 

// Other* op = static_cast<Other*>(s) ; 

// Conveniently gives an error message, while 
Other* op2 = (Other*)s; 

// does not 
} ///:- 


En este programa, se usa una nueva caracterlstica que no sera completamente 
descrita hasta el Volumen 2 de este libro, donde hay un capitulo que cubre este te- 
ma: Information de tipo en tiempo de ejecncion en C++ o mecanismo RTTI (run time type 
information). RTTI permite descubrir informacion de tipo que ha sido perdida en el 
upcasting. El moldeado dindmico es actualmente una forma de RTTI. Aqul se usa la pa- 
labra reservada typeid (declarada en el fichero cabecera typeinfo) para detectar 
el tipo de los punteros. Se puede ver que el tipo del puntero a Figura es comparado 
de forma sucesiva con un puntero a Circulo y con un Cuadrado para ver si exis- 
te alguna coincidencia. Hay mas RTTI que el typeid, y se puede imaginar que es 
facilmente implementable un sistema de informacion de tipos usando una funcion 
virtual. 

Se crea un objeto Circulo y la direccion es elevada a un puntero a Figur- 
a; la segunda version de la expresion muestra como se puede usar modeado estdtico 
para ser mas explicito con el upcast. Sin embargo, desde el momento que un upcast 
siempre es seguro y es una cosa que se hace comunmente, considero que un cast 
expllcito para hacer upcast ensucia el codigo y es innecesario. 

Para determinar el tipo se usa RTTI, y se usa modelado estdtico para realizar el 
downcast. Pero hay que resaltar que, efectivamente, en este diseno el proceso es el 
mismo que usar el moldeado dindmico, y el programador cliente debe hacer algun test 
para descubrir si el cast tuvo exito. Normalmente se prefiere una situacion mas de- 
terminista que la del ejemplo anterior para usar el modeado estdtico antes que el mol¬ 
deado dindmico (y hay que examinar detenidamente el diseno antes de usar moldeado 
dindmico). 

Si una jerarqula de clases no tiene funciones virtuales (que es un diseno cues- 
tionable) o si hay otra informacion que permite hacer un downcast seguro, es un 
poco mas rapido hacer el downcast de forma estatica que con el moldeado dindmico. 
Ademas, modeado estdtico no permitira realizar un cast fuera de la jerarqula, como un 
cast tradicional permitiria, por lo que es mas seguro. Sin enbargo, navegar de for¬ 
ma estatica por la jerarqula de clases es siempre arriesgado por lo que hay que usar 
moldeado dindmico a menos que sea una situacion especial. 


15.13. Resumen 

Polimorfismo - implementado en C++ con las funciones virtuales - significa "for¬ 
mas diferentes". En la programacion orientada a objetos, se tiene la misma vista (la 
interfaz comun en la clase base) y diferentes formas de usarla: las diferentes versio- 
nes de las funciones virtuales. 

Se ha visto en este capitulo que es imposible entender, ni siquiera crear, un ejem¬ 
plo de polimorfismo sin usar la abstraccion de datos y la herencia. El polimorfismo 
es una caracterlstica que no puede ser vista de forma aislada (como por ejemplo las 
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sentencias const y switch), pero sin embargo funciona unicamente de forma con- 
junta, como una parte de un "gran cuadro" de relaciones entre clases. La gente se 
vuelve a menudo confusa con otras caracteristicas no orientadas a objetos de C++ 
como es la sobrecarga y los argumentos por defecto, los cuales son presentados a 
veces como orientado a objetos. No nos liemos; si no hay ligadura dinamica, no hay 
polimorfismo. 

Para usar el polimorfismo - y por lo tanto, tecnicas orientadas a objetos - en los 
programas hay que ampliar la vision de la programacion para incluir no solo miem- 
bros y mensajes entre clases individuales, si no tambien sus puntos en comun y las 
relaciones entre ellas. Aunque requiere un esfuerzo significativo, es recompensado 
gracias a que se consigue mayor velocidad en el desarrollo, mejor organization de 
codigo, programas extensibles, y mayor mantenibilidad. 

El polimorfismo completa las caracteristicas de orientation a objetos del lenguaje, 
pero hay dos caracteristicas fundamentales mas en C++: plantillas (introducidas en 
el capitulo 16 y cubiertas en mayor detalle en el segundo volumen de este libro), y 
manejo de excepciones (cubierto en el Volumen 2). Estas caracteristicas nos propor- 
cionan un incremento de poder de cada una de las caracteristicas de la orientation a 
objetos: tipado abstracto de datos, herencia, y polimorfismo. 


15.14. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Cree una jerarquia simple "figura": una clase base llamada Figura y una clases 
derivadas llamadas Circulo, Cuadrado, y Triangulo. En la clase base, hay 
que hacer una funcion virtual llamada dibujar (), y sobreescribirla en las 
clases derivadas. Hacer un array de punteros a objetos Figura que se creen en 
el monton (heap) y que obligue a realizar upcasting de los punteros, y llamar 
a dibujar () a traves de la clase base para verificar el comportamiento de las 
funciones virtuales. Si el depurador lo soporta, intente ver el programa paso a 
paso. 

2. Modifique el Ejercicio 1 de tal forma que dibujar () sea una funcion virtual 
pura. Intente crear un objeto de tipo Figura. Intente llamar a la funcion virtual 
pura dentro del constructor y mire lo que ocurre. Dejandolo como una funcion 
virtual pura cree una definition para dibujar ( ). 

3. Aumentando el Ejercicio 2, cree una funcion que use un objeto Figura por 
valor e intente hacer un upcast de un objeto derivado como argumento. Vea lo 
que ocurre. Arregle la funcion usando una referencia a un objeto Figura. 

4. Modifique Cl 4 : Combined. cpp para que f () sea virtual en la clase base. 
Cambie el main () para que se haga un upcast y una llamada virtual. 

5. Modifique Instruments . cpp ahadiendo una funcion virtual preparar () . 
Llame a preparar ( ) dentro de tune (). 

6. Cree una jerarquia de herencia de Roedores: Raton, Gerbo, Hamster, etc. En 
la clase base, proporcione los metodos que son comunes a todos los roedores, y 
redefina aquellos en las clases derivadas para que tengan diferentes comporta- 
mientos dependiendo del tipo especifico de roedor. Cree un array de punteros 
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a Roedor, rellenelo con distintos tipos de roedores y llame a los metodos de la 
clase base para ver lo que ocurre. 

7. Modifique el Ejercicio 6 para que use un vector<Roedor*> en vez de un 
array de punteros. Asegurese que se hace un limpiado correcto de la memoria. 

8. Empezando con la jerarquia anterior de Roedor, herede un HamsterAzul de 
Hamster (si, existe algo asi, tuve uno cuando era nino), sobreescriba los meto¬ 
dos de la clase base y muestre que el codigo que llama a los metodos de clase 
base no necesitan cambiar para adecuarse el nuevo tipo. 

9. A partir de la jerarquia Roedor anterior, anadaun destructor no virtual, cree 
un objeto de la Hamster usando new, haga un upcast del puntero a Roedor*', 
y borre el puntero con delete para ver si no se llama a los destructores en la 
jerarquia. Cambie el destructor a virtual y demuestre que el comportamiento 
es ahora correcto. 

10. Modifique Roedor para convertirlo en una clase base pura abstracta. 

11. Cree un sistema de control aereo con la clase base Avion y varios tipos deriva- 
dos. Cree una clase Torre con un vector<Avion*> que envie los mensajes 
adecuados a los distintos aviones que estan bajo su control. 

12. Cree un modelo de invernadero heredando varios tipos de PI ant as y constru- 
yendo mecanismos en el invernadero que se ocupen de las plantas. 

13. En Early . cpp, haga a Pet una clase base abstracta pura. 

14. En AddingVirtuals . cpp, haga a todas las funciones miembro de Pet vir- 
tuales puras, pero proporcione una definicion para name () . Arregle Dog como 
sea necesario, usando la definicion de name () que se encuentra en la clase ba¬ 
se. 

15. Escriba un pequeno programa para mostrar la diferencia entre llamar a una 
funcion virtual dentro de una funcion miembro normal y llamar a una funcion 
virtual dentro de un constructor. El programa de probar que las dos llamadas 
producen diferentes resultados. 

16. Modifique VirtualsInDestructors . cpp por heredando una clase de D- 
erived y sobreescribiendo f () y el destructor. En main () , cree y haga un 
upcast de un objeto de su nuevo tipo, despues borrelo. 

17. Use el Ejercicio 16 y anada llamadas a f () en cada destructor. Explique que 
ocurre. 

18. Cree un clase que tenga un dato miembro y una clase derivada que anada otro 
da to miembro. Escriba una funcion no miembro que use un objeto de la clase 
base por valor e imprima el tamano del objeto usando sizeof. En el main ( ) 
cree un objeto de la clase derivada, imprima su tamano, y llame a su funcion. 
Explique lo que ocurre. 

19. Cree un ejemplo sencillo de una llamada a una funcion virtual y genere su 
salida en ensamblador. Localize el codigo en ensamblador para la llamada a la 
funcion virtual y explique el codigo. 

20. Escriba una clase con una funcion virtual y una funcion no virtual. Herede una 
nueva clase, haga un objeto de esa clase, y un upcast a un puntero del tipo de la 
clase base. Use la funcion clock () que se encuentra en <ctime> (necesitara 
echar un vistazo a su libreri C) para medir la diferencia entre una llamada 
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virtual y una llamada no virtual. Sera necesario realizar multiples llamadas a 
cada funcion para poder ver la diferencia. 

21. Modifique Cl 4 : Order . cpp anadiendo una funcion virtual en la clase base 
de la macro CLASS (que pinte algo) y haciendo el destructor virtual. Cree ob- 
jetos de las distintas subclases y hagales un upcast a la clase base. Verifique 
que el comportamiento virtual funciona y que se realiza de forma correcta la 
construction y la destruction del objeto. 

22. Escriba una clase con tres funciones virtuales sobrecargadas. Herede una nue- 
va clase y sobreescriba una de las funciones. Cree un objeto de la clase deriva- 
da. ^Se puede llamar a todas las funciones de la clase base a traves del objeto 
derivado? Haga un upcast de la direction del objeto a la base. ^Se pueden lla¬ 
mar a las tres funciones a traves de la base? Elimine la definition sobreescrita 
en la clase derivada. Ahora ^Se puede llamar a todas las funciones de la clase 
base a traves del objeto derivado?. 

23. Modifique VariantReturn . cpp para que muestre que su comportamiento 
funciona con referencias igual que con punteros. 

24. En Early. cpp, ^Como se le puede indicar al compilador que haga la llama¬ 
da usando ligadura estatica o ligadura dinamica? Determine el caso para su 
propio compilador. 

25. Cree una clase base que contenga una funcion clone ( ) que devuelva un pun- 
tero a una copia del objeto actual. Derive dos subclases que sobreescriban clo¬ 
ne ( ) para devolver copias de sus tipos especificos. En el main (), cree y haga 
upcast de sus dos tipos derivados, y llame a clone () para cada uno y verifi¬ 
que que las copias clonadas son de los subtipos correctos. Experimente con su 
funcion clone () para que se pueda ir al tipo base, y despues intente regresar 
al tipo exacto derivado. ^Se le ocurre alguna situation en la que sea necesario 
esta aproximacion? 

26. Modifique OStackTest. cpp creando su propia clase, despues haga multiple 
herencia con Object para crear algo que pueda ser introducido en la pila. 
Pruebe su clase en el main (). 

27. Anada un tipo llamado Tensor a OperartorPolymorphism. cpp. 

28. (Intermedio) Cree una clase base X sin datos miembro y sin constructor, pero 
con una funcion virtual. Cree una Y que herede de X, pero sin un constructor 
explicito. Genere codigo ensamblador y examinelo para deteriminar si se crea 
y se llama un constructor de X y, si eso ocurre, que codigo lo hace. Explique lo 
que haya descubierto. X no tiene constructor por defecto, entonces ,j,por que no 
se queja el compilador? 

29. (Intermedio) Modifique el Ejercicio 28 escribiendo constructores para ambas 
clases de tal forma que cada constructor llame a una funcion virtual. Genere el 
codigo ensamblador. Determine donde se encuentra asignado el VPTR dentro 
del constructor. ^E1 compilador esta usando el mecanismo virtual dentro del 
constructor? Explique por que se sigue usando la version local de la funcion. 

30. (Avanzado) Si una funcion llama a un objeto pasado por valor si ligadura es¬ 
tatica, una llamada virtual accede a partes que no existen. ^Es posible? Escriba 
un codigo para forzar una llamada virtual y vea si se produce un cuelgue de la 
aplicacion. Para explicar el comportamiento, observe que ocurre si se pasa un 
objeto por valor. 



'Volumenl" — 2012/1/12 — 13:52 — page 477 — #515 


15.14. Ejercicios 


31. (Avanzado) Encuentre exactamente cuanto tiempo mas es necesario para una 
llamada a una funcion virtual buscando en la informacion del lenguaje ensam- 
blador de su procesador o cualquier otro manual tecnico y encontrando los 
pulsos de reloj necesarios para una simple llamada frente al numero necesario 
de las instrucciones de las funciones virtuales. 

32. Determine el tamano del VPTR (usando sizeof) en su implementation. Aho- 
ra herede de dos clases (herencia multiple) que contengan funciones virtuales. 
iSe tiene una o dos VPTR en la clase derivada? 

33. Cree una clase con datos miembros y funciones virtuales. Escriba una funcion 
que mire en la memoria de un objeto de su clase y que imprima sus distintos 
fragmentos. Para hacer esto sera necesario experimentar y de forma iterativa 
descubrir donde se encuentra alojado el VPTR del objeto. 

34. Imagine que las funciones virtuales no existen, y modifique Instrument 4 . 
cpp para que use moldeado dindmico para hacer el equivalente de las llamadas 
virtuales. Esplique porque es una mala idea. 

35. Modifique StaicHierarchyNavigation. cpp para que en vez de usar el 
RTTI de C++ use su propio RTTI via una funcion virtual en la clase base llama¬ 
da what Ami () yunenum type { Circulos, Cuadrados };. 

36. Comience con PointerToMemberOperator . cpp del capitulo 12 y demues- 
tre que el polimorfismo todavia funciona con punteros a miembros, incluso si 
operator->* esta sobrecargado. 
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16: Introduccion a las Plantillas 

La herencia y la composition proporcionan una forma de retilizar 
codigo objeto. Las plantillas de C++ proporcionan una manera de 
reutilizar el codigo fuente. 

Aunque las plantillas (o templates) son una herramienta de programacion de 
proposito general, cuando fueron introducidos en el lenguaje, parecian oponerse 
al uso de las jerarquias de clases contenedoras basadas en objetos (demostrado al 
final del Capitulo 15). Ademas, los contenedores y algoritmos del C++ Standard 
(explicados en dos capitulos del Volumen 2 de este libro, que se puede bajar de 
www.BruceEckel.com) estan construidos exclusivamente con plantillas y son rela- 
tivamente faciles de usar por el programador. 

Este capitulo no solo muestra los fundamentos de los templates, tambien es una 
introduccion a los contenedores, que son componentes fundamentales de la progra¬ 
macion orientada a objetos lo cual se evidencia a traves de los contenedores de la 
libreria estandar de C++. Se vera que este libro ha estado usando ejemplos conte¬ 
nedores - Stash y Stack- para hacer mas sencillo el concepto de los contenedores; 
en este capitulo se sumara el concepto del iterator. Aunque los contenedores son 
el ejemplo ideal para usarlos con las plantillas, en el Volumen 2 (que tiene un ca¬ 
pitulo con plantillas avanzadas) se aprendera que tambien hay otros usos para los 
templates. 


16.1. Contenedores 

Supongase que se quiere crear una pila, como se ha estado haciendo a traves de 
este libro. Para hacerlo sencillo, esta clase manejara enteros. 

//: Cl6:IntStack.cpp 
// Simple integer stack 
//{L} fibonacci 

#include "fibonacci.h" 

#include /require.h" 

#include <iostream> 

using namespace std; 

class IntStack { 

enum { ssize = 100 }; 
int stack[ssize]; 
int top; 

public: 

IntStack() : top(O) {} 

void push (int i) { 
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require(top < ssize, "Too many push()es"); 
stack[top++] = i; 

} 

int pop () { 

require(top > 0, "Too many pop()s"); 
return stack[—top]; 



int main () { 

IntStack is; 

// Add some Fibonacci numbers, for interest: 
for(int i = 0; i < 20; i++) 
is.push(fibonacci(i)); 

// Pop & print them: 
for(int k = 0; k < 20; k++) 
cout << is.pop () << endl; 

} ///:- 


La clase IntStack es un ejemplo trivial de una pila. Para mantener la simplici- 
dad ha sido creada con un tamano fijo, pero se podria modificar para que automati- 
camente se expanda usando la memoria del monton, como en la clase Stack que ha 
sido examinada a traves del libro. 

main () anade algunos enteros a la pila, y posteriormente los extrae. Para hacer el 
ejemplo mas interesante, los enteros son creados con la funcion f ibonacci (), que 
genera los tradicionales numeros de la reproduction del conejo. Aqui esta el archivo 
de cabecera que declara la funcion: 

//: Cl6:fibonacci.h 
// Fibonacci number generator 
int fibonacci (int n); ///:- 


Aqui esta la implementation: 

//: C16:fibonacci.cpp {0} 

#include /require.h" 

int fibonacci (int n) { 
const int sz = 100; 
require(n < sz); 

static int f [sz] ; // Initialized to zero 

f [0] = f [13 = 1; 

// Scan for unfilled array elements: 

int i; 

for ( i = 0; i < sz; i++) 
if(f[i] == 0 ) break; 
while (i <= n) { 

mi = f [ i—1 ] + f [ i—2 ] ; 

i++; 

} 

return f [ n ]; 

} ///:~ 
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Esta es una implementation bastante eficiente, porque nunca se generan los nu- 
meros mas de una vez. Se usa un array static de int, y se basa en el hecho de 
que el compilador inicializara el array estatico a cero. El primer bucle for mueve el 
indice i a la primera position del array que sea cero, entonces un bucle while ana- 
de numeros Fibonacci al array hasta que se alcance el elemento deseado. Hay que 
hacer notar que si los numeros Fibonacci hasta el elemento n ya estan inicializados, 
entonces tambien se salta el bucle while. 


16.1.1. La necesidad de los contenedores 

Obviamente, una pila de enteros no es una herramienta crucial. La necesidad real 
de los contenedores viene cuando se empizan a crear objetos en el monton (heap) 
usando new y se destruyen con delete. En un problema general de programacion 
no se saben cuantos objetos van a ser necesarios cuando se esta escribiendo el pro- 
grama. Por ejemplo, en un sistema de control de trafico aereo no se quiere limitar el 
numero de aviones que el sistema pueda gestionar. No puede ser que el programa 
se aborte solo porque se excede algun numero. En un sistema de diseno asistido por 
computadora, se estan manejando montones de formas, pero unicamente el usuario 
determina (en tiempo de execution) cuantas formas seran necesarias. Una vez apre- 
ciemos estas tendencias, se descubriran montones de ejemplos en otras situaciones 
de programacion. 

Los programadores de C que dependen de la memoria virtual para manejar su 
"gestion de memoria" encuentran a menudo como perturbantentes las ideas del new, 
delete y de los contenedores de clases. Aparentemente, una practica en C es crear 
un enorme array global, mas grande que cualquier cosa que el programa parezca 
necesitar. Para esto no es necesario pensar demasiado (o hay que meterse en el uso 
de malloc () y free ()), pero se producen programas que no se pueden portar bien 
y que esconden sutiles errores. 

Ademas, si se crea un enorme array global de objetos en C++, la sobrecarga de los 
constructores y de los destructores pueden enlentecer las cosas de forma significati- 
va. La aproximacion de C++ funciona mucho mejor: Cuando se necesite un objeto, 
se crea con new, y se pone su puntero en un contenedor. Mas tarde, se saca y se 
hace algo con el. De esta forma, solo se crean los objetos cuando sea necesario. Y 
normalmente no se dan todas las condiciones para la initialization al principio del 
programa. new permite esperar hasta que suceda algo en el entorno para poder crear 
el objeto. 

Asi, en la situation mas comun, se creara un contenedor que almacene los pun- 
teros de algunos objetos de interes. Se crearan esos objetos usando new y se pon- 
dra el puntero resultante en el contenedor (potencialmete haciendo upcasting en el 
proceso), mas tarde el objeto se puede recuperar cuando sea necesario. Esta tecnica 
produce el tipo de programas mas flexible y general. 


16.2. Un vistazo a las plantillas 

Ahora surge un nuevo problema. Tenemos un IntStack, que maneja enteros. 
Pero queremos una pila que maneje formas, o flotas de aviones, o plantas o cualquier 
otra cosa. Reinventar el codigo fuente cada vez no parece una aproximacion muy 
inteligente con un lenguaje que propugna la reutilizacion. Debe haber un camino 
mejor. 

Hay tres tecnicas para reutilizar codigo en esta situation: el modo de C, presen- 
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tado aqui como contraste; la aproximacion de Smalltalk, que afecto de forma signifi- 
cativa a C++, y la aproximacion de C++: los templates. 

La solution de C. Por supuesto hay que escapar de la aproximacion de C porque 
es desordenada y provoca errores, al mismo tiempo que no es nada elegante. En esta 
aproximacion, se copia el codigo de una Stack y se hacen modificaciones a mano, 
introduciendo nuevos errores en el proceso. Esta no es una tecnica muy productiva. 

La solution de Smalltalk. Smalltalk (y Java siguiendo su ejemplo) opto por una 
solucion simple y directa: Se quiere reutilizar codigo, pues utilicese la herencia. Para 
implementarlo, cada clase contenedora maneja elementos de una clase base generica 
llamada Object (similar al ejemplo del final del capitulo 15). Pero debido a que la 
libreria de Smalltalk es fundamental, no se puede crear una clase desde la nada. En 
su lugar, siempre hay que heredar de una clase existente. Se encuentra una clase lo 
mas cercana posible a lo que se desea, se hereda de ella, y se hacen un par de cambios. 
Obviamente, esto es un beneficio porque minimiza el trabajo (y explica porque se 
pierde un monton de tiempo aprendiendo la libreria antes de ser un programador 
efectivo en Smalltalk). 

Pero tambien significa que todas las clases de Smalltalk acaban siendo parte de 
un unico arbol de herencia. Hay que heredar de una rama de este arbol cuando se 
esta creando una nueva clase. La mayoria del arbol ya esta alii (es la libreria de clases 
de Smalltalk), y la raiz del arbol es una clase llamada Object - la misma clase que 
los contenedores de Smalltalk manejan. 

Es un truco ingenioso porque significa que cada clase en la jerarquia de herencia 
de Smalltalk (y Java 1 ) se deriva de Object, por lo que cualquier clase puede ser 
almacenada en cualquier contenedor (incluyendo a los propios contenedores). Este 
tipo de jerarquia de arbol unica basada en un tipo generico fundamental (a menu- 
do llamado Object, como tambien es el caso en Java) es conocido como "jerarquia 
basada en objectos". Se puede haber oido este temino y asumido que es un nuevo 
concepto fundamental de la POO, como el polimorfismo. Sin embargo, simplemente 
se refiere a la raiz de la jerarquia como Object (o algun temino similar) y a conte¬ 
nedores que almacenan Objects. 

Debido a que la libreria de clases de Smalltalk tenia mucha mas experiencia e 
historia detras de la que tenia C++, y porque los compiladores de C++ originales 
no tenian librerias de clases contenedoras, parecia una buena idea duplicar la libre¬ 
ria de Smalltalk en C++. Esto se hizo como experimento con una de las primeras 
implementaciones de C++ 2 , y como representaba un significativo ahorro de codigo 
mucha gente empezo a usarlo. En el proceso de intentar usar las clases contenedoras, 
descubrieron un problema. 

El problema es que en Smalltalk (y en la mayoria de los lenguajes de POO que yo 
conozco), todas las clases derivan automaticamente de la jerarquia unica, pero esto 
no es cierto en C++. Se puede tener una magnifica jerarquia basada en objetos con 
sus clases contenedoras, pero entonces se compra un conjunto de clases de figuras, 
o de aviones de otro vendedor que no usa esa jerarquia. (Esto se debe a que usar 
una jerarquia supone sobrecarga, rechazada por los programadores de C). ^Como 
se inserta un arbol de clases independientes en nuestra jerarquia? El problema se 
parece a lo siguiente: 


1 Con la exception, en Java, de los tipos de datos primitivos, que se hicieron no Ob j ects por eficiencia. 

2 La libreria OOPS, por Keith Gorlen, mientras estaba en el NIH. 
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Figura 16.1: Contenedores 


Debido a que C++ suporta multiples jerarqulas independientes, la jerarqula ba- 
sada en objetos de Smalltalk no funciona tan bien. 

La solucion parace obvia. Si se pueden tener multiples jerarqulas de herencia, 
entonces hay que ser capaces de heredar de mas de una clase: La herencia multiple 
resuelve el problema. Por lo que se puede hacer lo siguiente (un ejemplo similar se 
dio al final del Capltulo 15). 



Figura 16.2: Flerencia multiple 


Ahora OShape tiene las caracterlsticas y el comportamiento de Shape, pero como 
tambien esta derivado de Object puede ser insertado en el contenedor. La herencia 
extra dada a OCircle, OSquare, etc. es necesaria para que esas clases puedanhacer 
upcast hacia OShape y puedan mantener el comportamiento correcto. Se puede ver 
como las cosas se estan volviendo confusas rapidamente. 

Los vendedores de compiladores inventaron e incluyeron sus propias jerarqulas y 
clases contenedoras, muchas de las cuales han sido reemplazadas desde entonces por 
versiones de templates. Se puede argumentar que la herencia multiple es necesaria 
para resolver problemas de programacion general, pero como se vera en el Volumen 
2 de este libro es mejor evitar esta complejidad excepto en casos especiales. 


16.2.1. La solucion de la plantilla 

Aunque una jerarqula basada en objetos con herencia multiple es conceptual- 
mente correcta, se vuelve diflcil de usar. En su libro 3 , Stroustrup demostro lo que el 
consideraba una alternativa preferible a la jerarqula basada en objetos. Clases con¬ 
tenedoras que fueran creadas como grandes macros del preprocesador con argu- 
mentos que pudieran ser sustituidos con el tipo deseado. Cuando se quiera crear un 


3 The C++ Programming Language by Bjarne Stroustrup (l a edition, Addison-Wesley, 1986) 
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contenedor que maneje un tipo en concreto, se hacen un par de llamadas a macros. 

Desafortunadamente, esta aproximacion era confusa para toda la literatura exis- 
tente de Smalltalk y para la experiencia de programacion, y era un poco inmanejable. 
Basicamente, nadie la entendia. 

Mientras tanto, Stroustrup y el equipo de C++ de los Laboratories Bell habian 
modificado su aproximacion de las macros, simplificandola y moviendola del domi- 
nio del preprocesador al compilador. Este nuevo dispositivo de sustitucion de codigo 
se conoce como template 4 (plantilla), y representa un modo completamente dife- 
rente de reutilizar el codigo. En vez de reutilizar codigo objeto, como en la herencia 
y en la composicion, un template reutiliza codigo fuente. El contenedor no maneja una 
clase base generica llamada Object, si no que gestiona un parametro no especifica- 
do. Cuando se usa un template, el parametro es sustituido por el compilador, parecido 
a la antigua aproximacion de las macros, pero mas claro y facil de usar. 

Ahora, en vez de preocuparse por la herencia o la composicion cuando se quiera 
usar una clase contenedora, se usa la version en plantilla del contenedor y se crea 
una version especlfica para el problema, como lo siguiente: 



Figura 16.3: Contenedor de objetos Figura 


El compilador hace el trabajo por nosotros, y se obtiene el contenedor necesario 
para hacer el trabajo, en vez de una jerarquia de herencia inmanejable. En C++, el 
template implementa el concepto de tipo parametrizado. Otro beneficio de la aproxi¬ 
macion de las plantillas es que el programador novato que no tenga familiaridad o 
este incomodo con la herencia puede usar las clases contenedoras de manera ade- 
cuada (como se ha estado haciendo a lo largo del libro con el vector). 


16.3. Sintaxis del Template 

La palabra reservada template le dice al compilador que la definicion de clases 
que sigue manipulara uno o mas tipos no especificados. En el momento en que el 
codigo de la clase actual es generado, los tipos deben ser especificados para que el 
compilador pueda sustituirlos. 

Para demostrar la sintaxis, aqui esta un pequeno ejemplo que produce un array 
con limites comprobados: 

//: Cl6:Array.epp 

#include /require.h" 

#include <iostream> 

using namespace std; 

templatecclass T> 

4 La inspiration de los templates parece venir de los generics de ADA 
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class Array { 

enum { size = 100 }; 

T A[size]; 

public: 

T& operator!](int index) { 

require(index >= 0 && index < size, 
"Index out of range"); 
return A[index]; 


} ; 


int main () { 

Array<int> ia; 

Array<float> fa; 
for(int i = 0; i < 20; i++) { 

ia[i] = i * i; 
fa[i] = float(i) * 1.414; 

} 

for(int j=0; j<20; j++) 

cout << j << " << ia[j] 

« ", " « fa [ j j « endl; 

} ///:~ 


Se puede ver que parece una clase normal excepto por la lmea. 

template<class T> 


que indica que T es un parametro de sustitucion, y que representa un nombre de 
un tipo. Ademas, se puede ver que T es usado en todas las partes de la clase donde 
normalmente se vena al tipo espedfico que el contenedor gestiona. 

En Array los elementos son insertados y extraidos con la misma funcion: el ope- 
rador sobrecargado operator [ ]. Devuelve una referenda, por lo que puede ser 
usado en ambos lados del signo igual (es decir, tanto como lvalue como rvalue). 
Hay que hacer notar que si el tndice se sale de los llmites se usa la funcion requir- 
e () para mostrar un mensaje. Como operator [ ] es inline, se puede usar esta 
aproximacion para garantizar que no se producen violaciones del lfmite del array 
para entonces eliminar el require (). 

En el main (), se puede ver lo facil que es crear Arrays que manejen distintos 
tipos de objetos. Cuando se dice: 

Array<int> ia; 

Array<float> fa; 


el compilador expande dos veces la plantilla del Array (que se conoce como 
instantiation o crear una instancia), para crear dos nuevas clases generadas, 
las cuales pueden ser interpretadas como Array_int y Array_float. Diferen- 
tes compiladores pueden crear los nombres de diferentes maneras. Estas clases son 
identicas a las que hubieran producido de estar hechas a mano, excepto que el com¬ 
pilador las crea por nosotros cuando se definen los objetos ia y f a. Tambien hay 
que notar que las definiciones de clases duplicadas son eludidas por el compilador. 
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16.3.1. Definiciones de funcion no inline 

Por supuesto, hay veces en las que se querra tener definicion de funciones no 
inline. En ese caso, el compilador necesita ver la declaracion del template antes 
que la definicion de la funcion miembro. Aqui esta el ejemplo anterior, modificado 
para mostrar la definicion del miembro no inline. 

//: Cl6:Array2.cpp 

// Non-inline template definition 

#include "../require.h" 

template<class T> 
class Array { 

enum { size = 100 }; 

T A[size]; 

public: 

T& operator!](int index); 

} ; 


template<class T> 

T& Array<T>:: operator[](int index) { 
require(index >= 0 && index < size, 
"Index out of range"); 
return A[index]; 

} 


int main () { 

Array<float> fa; 
fa[0] = 1.414; 

} ///:~ 


Cualquier referencia al nombre de una plantilla de clase debe estar acompanado 
por la lista de argumentos del template, como en Array<T>operator [ ]. Se puede 
imaginar que internamente, el nombre de la clase se rellena con los argumentos de 
la lista de argumentos de la plantilla para producir un nombre identificador unico 
de la clase for cada instanciacion de la plantilla. 

Archivos cabecera 

Incluso si se crean definiciones de funciones no inline, normalmente se querra 
poner todas las declaraciones y definiciones de un template en un archivo cabecera. 
Esto parece violar la regia usual de los archivos cabecera de «No poner nada que 
asigne almacenamiento», (lo cual previene multiples errores de definicion en tiem- 
po de enlace), pero las definiciones de plantillas son especial. Algo precedido por 
template< . . . > significa que el compilador no asignara almacenamiento en ese 
momenta, sino que se esperara hasta que se lo indiquen (en la instanciacion de una 
plantilla), y que en algun lugar del compilador y del enlazador hay un mecanismo 
para eliminar las multiples definiciones de una plantilla identica. Por lo tanto ca- 
si siempre se pondra toda la declaracion y definicion de la plantilla en el archivo 
cabecera por facilidad de uso. 

Hay veces en las que puede ser necesario poner las definiciones de la plantilla 
en un archivo cpp separado para satisfacer necesidades especiales (por ejemplo, 
forzar las instanciaciones de las plantillas para que se encuentren en un unico archivo 
dll de Windows). La mayoria de los compiladores tienen algun mecanismo para 
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permitir esto; hay que investigar la documentacion del compilador concreto para 
usarlo. 

Algunas personas sienten que poner el codigo fuente de la implementacion en 
un archivo cabecera hace posible que se pueda robar y modificar el codigo si se 
compra la librerla. Esto puede ser una caracterlstica, pero probablemente dependa 
del modo de mirar el problema: ^Se esta comprando un producto o un servicio? Si es 
un producto, entonces hay que hacer todo lo posible por protegerlo, y probablemente 
no se quiera dar el codigo fuente, sino solo el codigo compilado. Pero mucha gente 
ve el software como un servicio, incluso mas, como un servicio por suscripcion. El 
cliente quiere nuestra pericia, quieren que se mantenga ese fragmento de codigo 
reutilizable para no tenerlo que hacer el - para que se pueda enfocar en hacer su 
propio trabajo. Personalmente creo que la mayorla de los clientes le trataran como 
una fuente de recursos a tener en cuenta y no querran poner en peligro su relacion 
con usted. Y para los pocos que quieran robar en vez de comprar o hacer el trabajo 
original, de todas formas probablemante tampoco se mantendrlan con usted. 


16.3.2. IntStack como plantilla 

Aqul esta el contenedor y el iterador de IntStack. cpp, implementado como 
una clase contenedora generica usando plantillas: 

//: Cl6:StackTemplate.h 
// Simple stack template 

#ifndef STACKTEMPLATE_H 
#define STACKTEMPLATE_H 

#include "../require.h" 

template<class T> 
class StackTemplate f 
enum { ssize = 100 }; 

T stack[ssize]; 

int top; 

public: 

StackTemplate() : top(0) {} 

void push (const T& i) { 

require(top < ssize, "Too many push()es"); 
stack[top++] = i; 

} 

T pop() { 

require(top > 0, "Too many pop()s"); 
return stack[--top]; 

} 

int size () { return top; } 

} ; 

#endif // STACKTEMPLATE_H ///:- 


Hay que darse cuenta que esta plantilla asume ciertas caracterlsticas de los ob- 
jetos que esta manejando. Por ejemplo, StackTemplate asume que hay alguna 
clase de operacion de asignacion a r dentro de la funcion push (). Se puede decir 
que una plantilla «implica una interfaz» para los tipos que es capaz de manejar. 

Otra forma de decir esto es que las plantillas proporcionan una clase de meca- 
nismo de tipado debil en C++, lo cual es tlpico en un lenguaje fuertemente tipado. En 
vez de insistir en que un objeto sea del mismo tipo para que sea aceptable, el tipado 
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debil requiere unicamente que la funcion miembro a la que se quiere llamar este dis- 
ponible para un objeto en particular. Es decir, el codigo debilmente tipado puede ser 
aplicado a cualquier objeto que acepte esas llamadas a funciones miembro, lo que lo 
hace mucho mas flexible 3 . 

Aqui tenemos el objeto revisado para comprobar la plantilla: 

//: Cl6:StackTemplateTest.cpp 
// Test simple stack template 
//{L} fibonacci 

#include "fibonacci.h" 

#include "StackTemplate.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

int main() { 

StackTemplate<int> is; 
for (int i = 0; i < 20; i++) 
is.push (fibonacci (i)); 
for (int k = 0; k < 20; k++) 
cout << is.pop () << endl; 
ifstream in("StackTemplateTest.cpp"); 
assure(in, "StackTemplateTest.cpp"); 
string line; 

StackTemplate<string> strings; 
while (getline(in, line)) 
strings.push(line); 
while (strings.size() > 0) 

cout << strings.pop() << endl; 

1 // / : ~ 


La unica diferencia esta en la creacion de is. Dentro de la lista de argumentos 
del template hay que especificar el tipo de objeto que la pila y el iterador deberan 
manejar. Para demostrar la genericidad de la plantilla, se crea un StackTemplate 
para manejar string. El ejemplo lee las lineas del archivo con el codigo fuente. 


16.3.3. Constantes en los Templates 

Los argumentos de los templates no restrigen su uso a tipos class; se pueden tam- 
bien usar tipos empotrados. Los valores de estos argumentos se convierten en cons¬ 
tantes en tiempo de compilacion para una instanciacion en particular de la plantilla. 
Se pueden usar incluso valores por defecto para esos argumentos. El siguiente ejem¬ 
plo nos permite indicar el tamano de la clase Array durante la instanciacion, pero 
tambien proporciona un valor por defecto: 

//: Cl6:Array3.cpp 

// Built-in types as template arguments 

#include "../require.h" 

#include <iostream> 

using namespace std; 

3 Todos los metodos en Smalltalk y Python estan debilmente tipados, y ese es el motivo por lo que es¬ 
tos lenguajes no necesitan el mecanismo de los templates. En efecto, se consiguen plantillas sin templates. 
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template<class T, int size = 100> 
class Array { 

T array[size]; 

public: 

T& operator!](int index) { 

require(index >= 0 SS index < size, 
"Index out of range"); 
return array[index]; 

} 

int length() const { return size; } 


class Number { 
float f; 
public: 

Number (float ff = O.Of) : f(ff) {} 

Numbers operator=(const Numbers n) { 
f = n . f ; 

return *this; 

} 

operator float() const { return f; } 

friend ostreams 

operator« (ostreamS os, const Numbers x) { 

return os << x.f; 


} ; 


template<class T, int size = 20> 
class Holder { 

Array<T, size>* np; 

public: 

Holder() : np(0) { } 

TS operator!](int i) { 

require(0 <= i SS i < size); 
if(!np) np = new Array<T, size>; 

return np->operator[ ] (i) ; 

} 

int length() const { return size; } 
-Holder() { delete np; } 


int main() { 


Holder<Number> 

h; 



for(int i = 

0; 

i 

< 20; 

i++ 

h[i] = i; 

for(int j = 

0; 

j 

< 20; 

j++ 

cout << h 

[ j] 

<< 

endl; 



} ///:- 


Como antes. Array es un array de objetos que previene de rebasar los llmites. 
La clase Holder es muy parecida a Array excepto que tiene un puntero a Array 
en vez de un tener incrustrado un objeto del tipo Array. Este puntero no se inicializa 
en el constructor; la inicializacion es retrasada hasta el primer acceso. Esto se conoce 
como inicializacion perezosa ; se puede usar una tecnica como esta si se estan creando 
un monton de objetos, pero no se esta accediendo a todos ellos y se quiere ahorrar 
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almacenamiento. 

Hay que resaltar que nunca se almacena internamente el valor de size en la 
clase, pero se usa como si fuera un dato interno dentro de las funciones miembro. 


16.4. Stack y Stash como Plantillas 

Los problemas recurrentes de «propiedad» con las clases contenedoras Stack 
y Stash (Pila y Cola respectivamente) que han sido usadas varias veces a traves 
del libro, vienen del hecho de que estos contenedores no son capaces de saber exac- 
tamente que tipo manejan. Lo mas cerca que han estado es en el «contenedor» de 
objectos Stack que se vio al final del capitulo 15 en OStackTest. cpp. 

Si el programador cliente no elimina explicitamente todos los punteros a objeto 
que estan almacenados en el contenedor, entonces el contenedor deberia ser capaz 
de eliminar esos punteros de manera adecuada. Es decir, el contenedor «posee» cual- 
quiera de los objetos que no hayan sido eliminados, y es el responsable de limpiarlos. 
La dificultad radica en que el limpiado requiere conocer el tipo del objeto, y crear un 
contenedor generico no requiere conocer el tipo de ese objeto. Con los templates, sin 
embargo, podemos escribir codigo que no conozcan el tipo de objeto, y facilmente 
instanciar una nueva version del contenedor por cada tipo que queramos que con- 
tenga. La instancia contenedora individual conoce el tipo de objetos que maneja y 
puede por tanto llamar al destructor correcto (asumiendo que se haya proporciona- 
do un destructor virtual). 

Para la pila es bastante sencillo debido a todas las funciones miembro pueden ser 
introducidas en linea: 

//: Cl6:TStack.h 
// The Stack as a template 

#ifndef TSTACK_H 
#define TSTACK_H 

template<class T> 
class Stack { 
struct Link { 

T* data; 

Link* next; 

Link(T* dat, Link* nxt): 
data(dat), next (nxt) {} 

}* head; 

public: 

Stack () : head(0) {} 

-Stack(){ 
while (head) 

delete pop (); 

} 

void push(T* dat) { 

head = new Link(dat, head); 

} 

T* peek() const { 

return head ? head->data : 0; 

} 

T* pop(){ 

if (head == 0) return 0; 

T* result = head->data; 
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Link* oldHead = head; 
head = head->next; 
delete oldHead; 
return result; 

} 

} ; 

#endif // TSTACK_H ///:- 


Si se compara esto al ejemplo de OStack . h al final del capitulo 15, se vera que 
Stack es virtualmente identica, excepto que Object ha sido reemplazado con T. 
El programa de prueba tambien es casi identico, excepto por la necesidad de multiple 
herencia de string y Object (incluso por la necesidad de Object en si mismo) 
que ha sido eliminada. Ahora no tenemos una clase My St ring para anunciar su 
destruction por lo que anadimos una pequena clase nueva para mostrar como la 
clase contenedora Stack limpia sus objetos: 

//: Cl6:TStackTest.cpp 
//{T} TStackTest.cpp 

#include "TStack.h" 

#include /require.h" 

#include <fstream> 

#include <iostream> 

#include <string> 
using namespace std; 

class X { 
public: 

virtual ~X() { cout << "~X " << endl; } 

1 ; 


int main (int argc, char* argv[]) { 

requireArgs(argc, 1); // File name is argument 
ifstream in(argv[l]); 
assure(in, argv[l]); 

Stack<string> textlines; 
string line; 

// Read file and store lines in the Stack: 
while (getline(in, line)) 

textlines.push (new string(line)); 

// Pop some lines from the stack: 
string* s; 

for(int i = 0; i < 10; i++) { 

if((s = (string*)textlines.pop())==0 ) break; 
cout << *s << endl; 

delete s; 

} // The destructor deletes the other strings. 
// Show that correct destruction happens: 
Stack<X> xx; 

for (int j = 0; j < 10; j++) 

xx.push (new X); 

} ///:~ 


El destructor de X es virtual, no porque se sea necesario aqui, sino porque xx 
podria ser usado mas tarde para manejar objetos derivados de X. 
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Note lo facil que es crear diferentes clases de Stacks para string y para X. Debido 
a la plantilla, se consigue lo mejor de los dos mundos: la facilidad de uso de la Stack 
junto con un limpiado correcto. 


16.4.1. Cola de punteros mediante plantillas 

Reorganizar el codigo de P St ash en un template no es tan simple porque hay 
un numero de funciones miembro que no deben estar en lrnea. Sin embargo, como 
buena plantilla aquellas definiciones de funcion deben permanecer en el archivo ca- 
becera (el compilador y el enlazador se preocuparan por los problemas de multiples 
definiciones). El codigo parece bastante similar al PStash ordinario excepto que el 
tamano del incremento (usado por inf late ()) ha sido puesto en el template como 
un parametro no de clase con un valor por defecto, para que el tamano de incre¬ 
mento pueda ser modificado en el momento de la instanciacion (esto significa que 
el tamano es fijo aunque se podria argumentar que el tamano de incremento deberia 
ser cambiable a lo largo de la vida del objeto): 

//: Cl6:TPStash.h 

#ifndef TPSTASH_H 
#define TPSTASH_H 

templatecclass T, int incr = 10> 
class PStash { 

int quantity; // Number of storage spaces 
int next; // Next empty space 
T** storage; 

void inflate (int increase = incr); 

public: 

PStash() : quantity(0), next(0), storage(0) {} 

-PStash(); 

int add(T* element); 

T* operator!](int index) const; // Fetch 
// Remove the reference from this PStash: 

T* remove (int index); 

// Number of elements in Stash: 

int count () const { return next; } 

} ; 


templatecclass T, int incr> 
int PStashcT, incr>::add(T* element) { 
if (next >= quantity) 
inflate(incr); 
storage[next++] = element; 
return (next - 1); // Index number 

} 


// Ownership of remaining pointers: 

templatecclass T, int incr> 

PStashcT, incr>::-PStash() { 

for(int i = 0; i c next; i++) { 

delete storage[i]; // Null pointers 
storage[i] =0; // Just to be safe 


OK 


delete []storage; 
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template<class T, int incr> 

T* PStash<T, incr>:: operator[](int index) const { 
require(index >= 0, 

"PStash::operator[] index negative"); 
if (index >= next) 

return 0; //To indicate the end 
require(storage[index] != 0, 

"PStash::operator[] returned null pointer"); 
// Produce pointer to desired element: 
return storage[index]; 


template<class T, int incr> 

T* PStash<T, incr>::remove (int index) { 

// operator!] performs validity checks: 

T* v = operator[] (index); 

// "Remove" the pointer: 

if (v != 0) storage[index] = 0; 

return v; 


template<class T, int incr> 

void PStash<T, incr>::inflate (int increase) { 
const int psz = sizeof(T*); 

T** st = new T*[quantity + increase]; 

memset(st, 0, (quantity + increase) * psz); 

memcpy(st, storage, quantity * psz); 

quantity += increase; 

delete []storage; // Old storage 

storage = st; // Point to new memory 

} 

#endif // TPSTASH_H ///:- 


El tamano del incremento por defecto es muy pequeno para garantizar que se 
produzca la llama da a inf late (). Esto nos asegura que funcione correctamente. 

Para comprobar el control de propiedad de PStack en template, la siguiente 
clase muestra informes de creacion y destruction de elementos, y tambien garan- 
tiza que todos los objetos que hayan sido creados sean destruidos. AutoCounter 
permitira crear objetos en la pila solo a los objetos de su tipo: 

//: Cl6:AutoCounter.h 

#ifndef AUTOCOUNTER_H 
#define AUTOCOUNTER_H 
#include /require.h" 

#include <iostream> 

#include <set> // Standard C++ Library container 

#include <string> 

class AutoCounter { 

static int count; 
int id; 

class CleanupCheck { 

std::set<AutoCounter*> trace; 

public: 

void add(AutoCounter* ap) { 
trace.insert(ap) ; 
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} 

void remove(AutoCounter* ap) { 
require (trace.erase (ap) == 1, 

"Attempt to delete AutoCounter twice"); 

} 

-CleanupCheck() { 

std::cout << "-CleanupCheck()"<< std::endl; 
require(trace.size() == 0, 

"All AutoCounter objects not cleaned up"); 


} ; 

static CleanupCheck verifier; 

AutoCounter () : id(counttt) { 

verifier.add (this); // Register itself 
std::cout << "created!" << id << "]" 

<< std::endl; 

} 

// Prevent assignment and copy-construction: 

AutoCounter (const AutoCounterS); 

void operator=(const AutoCounterS); 
public: 

// You can only create objects with this: 
static AutoCounter* create() { 

return new AutoCounter() ; 

} 

-AutoCounter() { 

std::cout << "destroying!" << id 
<< "]" << std::endl; 
verifier.remove (this) ; 

} 

// Print both objects and pointers: 

friend std::ostreamS operator<< ( 

std::ostreamS os, const AutoCounterS ac) { 
return os << "AutoCounter " << ac.id; 

} 

friend std::ostreamS operator<< ( 

std::ostreamS os, const AutoCounter* ac) { 
return os << "AutoCounter " << ac->id; 

} 

} ; 

#endif // AUTOCOUNTER_H ///:- 


La clase AutoCounter hace dos cosas. Primero, numera cada instancia de A- 
utoCounter de forma secuencial: el valor de este numero se guarda en id, y el 
numero se genera usando el dato miembro count que es static. 

Segundo, y mas complejo, una instancia estatica (llamada verifier) de la clase 
CleanupCheck se mantiene al tanto de todos los objetos AutoCounter que son 
creados y destruidos, y nos informa si no se han limpiado todos (por ejemplo si 
existe un agujero en memoria). Este comportamiento se completa con el uso de la 
clase set de la Libreria Estandar de C++, lo cual es un magmfico ejemplo de como 
las plantillas bien disenadas nos pueden hacer la vida mas facil (se podra aprender 
mas de los contenedores en el Volumen 2 de este libro). 

La clase set esta instanciada para el tipo que maneja; aqui hay una instancia 
que maneja punteros a AutoCounter. Un set permite que se inserte solo una 
instancia de cada objeto; en add () se puede ver que esto sucede con la funcion 
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set: : insert (). insert () nos informa con su valor de retorno si se esta inten- 
tando anadir algo que ya se habia incluido; sin embargo, desde el momenta en que 
las direcciones a objetos se inserten podemos confiar en C++ para que garantice que 
todos los objetos tengan direcciones unicas. 

En remove (), se usa set: : erase () para eliminar un puntero a AutoCou- 
nter del set. El valor de retorno indica cuantas instancias del elemento se han 
eliminado; en nuestro caso el valor puede ser unicamente uno o cero. Si el valor es 
cero, sin embargo, significa que el objeto ya habia sido borrado del conjunto y que 
se esta intentando borrar por segunda vez, lo cual es un error de programacion que 
debe ser mostrado mediante require (). 

El destructor de CleanupCheck hace una comprobacion final asegurandose de 
que el tamaho del set es cero - Lo que significa que todos los objetos han sido 
eliminados de manera adecuada. Si no es cero, se tiene un agujero de memoria, lo 
cual se muestra mediante el require (). 

El constructor y el destructor de AutoCounter se registra y desregistra con el 
objeto verifier. Hay que resaltar que el constructor, el constructor de copia, y el 
operador de asignacion son private, por lo que la unica forma de crear un objeto 
es con la funcion miembro static create () - esto es un ejemplo sencillo de una 

factory, y garantiza que todos los objetos sean creados en el montan (heap), por 
lo que verifier no se vera confundido con sobreasignaciones y construcciones de 
copia. 

Como todas las funciones miembro han sido definidas inline, la unica razon para 
el archivo de implementacion es que contenga las definiciones de los datos miembro: 

//: Cl6:AutoCounter.cpp {0} 

// Definition of static class members 
#include "AutoCounter.h" 

AutoCounter::CleanupCheck AutoCounter::verifier; 
int AutoCounter::count = 0; 

///:~ 


Con el AutoCounter en la mano, podemos comprobar las facilidades que pro- 
porciona el PStash. El siguiente ejemplo no solo muestra que el destructor de PS- 
tash limpia todos los objetos que posee, sino que tambien muestra como la clase 
AutoCounter detecta a los objetos que no se han limpiado. 

//: Cl6:TPStashTest.cpp 
//{L} AutoCounter 

#include "AutoCounter.h" 

#include "TPStash.h" 

#include <iostream> 

#include <fstream> 
using namespace std; 

int main() { 

PStash<AutoCounter> acStash; 
for(int i = 0; i < 10; i++) 

acStash.add(AutoCounter::create () ) ; 
cout << "Removing 5 manually:" << endl; 
for (int j = 0; j < 5; j++) 
delete acStash.remove(j); 
cout << "Remove two without deleting them:" 
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<< endl; 

// ... to generate the cleanup error message, 
cout << acStash.remove(5) << endl; 
cout << acStash.remove(6) << endl; 
cout << "The destructor cleans up the rest:" 
<< endl; 

// Repeat the test from earlier chapters: 
ifstream in ("TPStashTest.cpp"); 
assure(in, "TPStashTest.cpp"); 

PStash<string> stringStash; 
string line; 

while (getline(in, line)) 

stringStash.add (new string(line)); 

// Print out the strings: 

for(int u = 0; stringStash[u]; u++) 

cout << "stringStash[" << u << "] = " 

<< *stringStash[u] << endl; 

} ///:- 


Cuando se eliminan los elementos AutoCounter 5 y 6 de la PStash, se vuelve 
responsabilidad del que los llama, pero como el cliente nunca los borra se podrin 
producir agujeros de memoria, que serin detectados por AutoCounter en tiempo 
de ejecucion. 

Cuando se ejecuta el programa, se vera que el mensaje de error no es tan esped- 
fico como podria ser. Si se usa el esquema presentado en AutoCounter para des- 
cubrir agujeros de memoria en nuestro sistema, probablemente se quiera imprimir 
information mas detallada sobre los objetos que no se hayan limpiado. El Volumen 
2 de este libro muestra algunas formas mas sofisticadas de hacer esto. 


16.5. Activando y desactivando la propiedad 

Volvamos al problema del propietario. Los contenedores que manejan objetos por 
valor normalmente no se preocupan por la propiedad porque claramente poseen los 
objetos que contienen. Pero si el contenedor gestiona punteros (lo cual es comun en 
C++, especialmente con el polimorfismo), entonces es bastante probable que esos 
punteros sean usados en algun otro lado del programa, y no necesariamente se quie- 
re borrar el objeto porque los otros punteros del programa estaran referenciando a 
un objeto destruido. Para prevenir que esto ocurra, hay que considerar al propietario 
cuando se esta disenando y usando un contenedor. 

Muchos programas son mas simples que este, y no se encuentran con el problema 
de la propiedad: Un contenedor que maneja punteros a objetos y que son usados solo 
por ese contenedor. En este caso el propietario es evidente: El contenedor posee sus 
objetos. 

La mejor aproximacion para gestionar quien es el propietario es dar al programa- 
dor cliente una election. Esto se puede realizar con un argumento en el constructor 
que por defecto defina al propietario (el caso mas sencillo). Ademas habra que poner 
las funciones «get» y «set» para poder ver y modificar al propietario del contene¬ 
dor. Si el contenedor tiene funciones para eliminar un objeto, el estado de propiedad 
normalmente afecta a la funcion de eliminacion, por lo que se deberian encontrar op- 
ciones para controlar la destruction en la funcion de eliminacion. Es concebible que 
se anadan datos propietarios por cada elemento que contenga el contenedor, por lo 
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que cada posicion deberia saber cuando es necesario ser destruido; esto es una va- 
riante del conteo de references, excepto en que es el contenedor y no el objeto el que 
conoce el numero de referencias a un objeto. 

//: Cl6:OwnerStack.h 

// Stack with runtime conrollable ownership 

#ifndef OWNERSTACK_H 
#define OWNERSTACK_H 

template<class T> class Stack { 
struct Link { 

T* data; 

Link* next; 

Link(T* dat. Link* nxt) 

: data(dat), next (nxt) {} 

}* head; 
bool own; 
public: 

Stack (bool own = true) : head(0), own(own) {} 

-Stack (); 

void push(T* dat) { 

head = new Link(dat,head); 

} 

T* peek() const { 

return head ? head->data : 0; 

} 

T * pop (); 

bool owns() const { return own; } 
void owns (bool newownership) { 
own = newownership; 

} 

// Auto-type conversion: true if not empty: 

operator bool() const { return head != 0; } 

} ; 


template<class T> T* Stack<T>::pop() { 

if (head == 0) return 0; 

T* result = head->data; 

Link* oldHead = head; 
head = head->next; 
delete oldHead; 
return result; 

) 

template<class T> Stack<T>::-Stack() { 

if(!own) return; 
while (head) 
delete pop() ; 

} 

#endif // OWNERSTACK_H ///:- 


El comportamiento por defecto del contenedor consiste en destruir sus objetos 
pero se puede cambiar o modificando el argumento del constructor o usando las 
funciones miembro de owns (). 

Como con la mayoria de las plantillas que se veran, la implementation entera se 
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encuentra en el archivo de cabecera. Aqui tenemos un pequeno test que muestra las 
capacidades de la propiedad: 

//: Cl6:OwnerStackTest.cpp 
//{L} AutoCounter 

#include "AutoCounter.h" 

#include "OwnerStack.h" 

#include /require.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

int main() { 

Stack<AutoCounter> ac; // Ownership on 
Stack<AutoCounter> ac2 (false) ; // Turn it off 

AutoCounter* ap; 
for (int i = 0; i < 10; i++) { 

ap = AutoCounter::create (); 
ac.push(ap); 
if(i % 2 == 0) 
ac2.push (ap); 

} 

while (ac2) 

cout << ac2.pop() << endl; 

// No destruction necessary since 
// ac "owns" all the objects 
} /// : ~ 


El objeto ac2 no posee los objetos que pusimos en el, sin embargo ac es un 
contenedor «maestro» que tiene la responsabilidad de ser el propietario de los obje¬ 
tos. Si en algun momento de la vida de un contenedor se quiere cambiar el que un 
contenedor posea a sus objetos, se puede hacer usando owns (). 

Tambien seria posible cambiar la granularidad de la propiedad para que estuvie- 
ra en la base, es decir, objeto por objeto. Esto, sin embargo, probablemente haria a la 
solucion del problema del propietario mas complejo que el propio problema. 


16.6. Manejando objetos por valor 

Actualmente crear una copia de los objetos dentro de un contenedor generico 
seria un problema complejo si no se tuvieran plantillas. Con los templates las cosas 
se vuelven relativamente sencillas - solo hay que indicar que se estan manejando 
objetos en vez de punteros: 

//: Cl6:ValueStack.h 

// Holding objects by value in a Stack 

#ifndef VALUESTACK_H 
#define VALUESTACK_H 

#include "../require.h" 

template<class T, int ssize = 100> 
class Stack { 

// Default constructor performs object 
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// initialization for each element in array: 

T stack[ssize]; 
int top; 

public: 

Stack() : top(0) { } 

// Copy-constructor copies object into array: 
void push (const T& x) { 

require(top < ssize, "Too many push()es"); 
stack[toptt] = x; 

} 

T peek() const { return stack[top]; } 

// Object still exists when you pop it; 

// it just isn't available anymore: 

T pop() { 

require(top > 0, "Too many pop()s"); 
return stack[—top]; 

} 

} ; 

#endif // VALUESTACK_H ///:- 


El constructor de copia de los objetos contenidos hacen la mayoria del trabajo 
pasando y devolviendo objetos por valor. Dentro de push (), el almacenamiento del 
objeto en el array Stack viene acompanado con T : : operators Para garantizar 
que funciona, una clase llamada Se 1 f Counter mantiene una lista de las creaciones 
y construcciones de copia de los objetos. 

//: Cl6:SelfCounter.h 

#ifndef SELFCOUNTER_H 
#define SELFCOUNTER_H 
#include "ValueStack.h" 

#include <iostream> 

class SelfCounter { 

static int counter; 
int id; 
public: 

SelfCounter () : id(counter++) [ 

std::cout << "Created: " << id << std::endl; 

} 

SelfCounter (const SelfCounterS rv) : id(rv.id){ 
std::cout << "Copied: " << id << std::endl; 

} 

SelfCounter operator=(const SelfCounterS rv) { 
std::cout << "Assigned " << rv.id << " to " 

<< id << std::endl; 

return *this; 

} 

-SelfCounter() { 

std::cout << "Destroyed: "<< id << std::endl; 

} 

friend std::ostreamS operator<< ( 

std::ostreams os, const SelfCounterS sc) { 
return os << "SelfCounter: " << sc.id; 


#endif // SELFCOUNTER_H ///:- 
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//: C16:SelfCounter.cpp {0} 

#include "SelfCounter.h" 

int SelfCounter::counter = 0; ///:- 


//: Cl6:ValueStackTest.cpp 
//{L} SelfCounter 

#include "ValueStack.h" 

#include "SelfCounter.h" 

#include <iostream> 

using namespace std; 

int main() { 

Stack<SelfCounter> sc; 
for(int i = 0; i < 10; i++) 
sc.push (SelfCounter ()); 

// OK to peek(), result is a temporary: 
cout << sc.peek() << endl; 
for(int k = 0; k < 10; k++) 
cout << sc.pop () << endl; 

} // / : ~ 


Cuando se crea un contenedor Stack, el constructor por defecto del objeto a 
contener es ejecutado por cada objeto en el array. Inicialmente se veran 100 obje- 
tos SelfCounter creados sin ningun motivo aparente, pero esto es justamente la 
inicializacion del array. Esto puede resultar un poco caro, pero no existe ningun pro- 
blema en un diseno simple como este. Incluso en situaciones mas complejas si se 
hace a Stack mas general permitiendo que crezca dinamicamente, porque en la 
implementacion mostrada anteriormente esto implicaria crear un nuevo array mas 
grande, copiando el anterior al nuevo y destruyendo el antiguo array (de hecho, as! 
es como lo hace la clase vector de la Libreria Estandar de C++). 

16.7. Introduccion a los iteradores 

Un iterator es un objeto que se mueve a traves de un contenedor de otros 
objetos y selecciona a uno de ellos cada vez, sin porporcionar un acceso directo a la 
implementacion del contenedor. Los iteradores proporcionan una forma estandar de 
acceder a los elementos, sin importar si un contenedor proporciona alguna marnera 
de acceder a los elementos directamente. Se veran a los iteradores usados frecuente- 
mente en asociacion con clases contenedoras, y los iteradores son un concepto fun¬ 
damental en el diseno y el uso de los contenedores del Standard C++, los cuales son 
descritos en el Volumen 2 de este libro (que se puede bajar de www.BruceEckel.com. 
Un iterador es tambien un tipo de patron de diseno, lo cual es materia de un capitulo 
del Volumen 2. 

En muchos sentidos, un iterador es un «puntero elegante», y de hecho se vera que 
los iteradores normalmente ocultan la mayoria de las operaciones de los punteros. 
Sin embargo, al contrario que un puntero, el iterador es disenado para ser seguro por 
lo que es mucho menos probable de hacer el equivalente de avanzar atravesando el 
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final de un array (o si se hace, se encontrara mas facilmente). 

Considere el primer ejemplo de este capitulo. Aqui esta pero anadiendo un itera- 
dor sencillo: 

//: Cl6:IterlntStack.cpp 
// Simple integer stack with iterators 
//{L} fibonacci 

#include "fibonacci.h" 

#include /require.h" 

#include <iostream> 

using namespace std; 

class IntStack { 

enum { ssize = 100 }; 
int stack[ssize]; 

int top; 

public: 

IntStack() : top(0) {} 

void push (int i) { 

require(top < ssize, "Too many push()es"); 
stack[top++] = i; 

} 

int pop() { 

require(top > 0, "Too many pop()s"); 
return stack[--top]; 

} 

friend class IntStacklter; 

} ; 


// An iterator is like a "smart" pointer; 
class IntStacklter { 

IntStackS s; 
int index; 

public: 

IntStacklter(IntStacks is) : s (is), index (0) {} 

int operator++() { // Prefix 
require(index < s.top, 

"iterator moved out of range"); 
return s.stack[++index]; 

} 

int operator++(int) { // Postfix 

require(index < s.top, 

"iterator moved out of range"); 
return s.stack[index++]; 


} ; 


int main () { 

IntStack is; 

for (int i = 0; i < 20; !.++) 
is.push(fibonacci (i) ) ; 

// Traverse with an iterator: 
IntStacklter it (is); 
for(int j = 0; j<20; j++) 
cout << it++ << endl; 

} ///:~ 
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El IntStacklter ha sido creado para trabajar solo con un IntStack. Hay 
que resaltar que IntStacklter es un friend de IntStack, lo que lo da un 
acceso a todos los elementos privados de IntStack. 

Como un puntero, el trabajo de IntStacklter consiste en moverse a traves 
de un IntStack y devolver valores. En este sencillo ejemplo, el objeto IntSta¬ 
cklter se puede mover solo hacia adelante (usando la forma prefija y sufija del 
operador++ ). Sin embargo, no hay limites de la forma en que se puede definir un 
iterador a parte de las restricciones impuestas por el contenedor con el que trabaje. 
Esto es totalmente aceptable (incluido los limites del contenedor que se encuentre 
por debajo) para un iterador que se mueva de cualquier forma por su contenedor 
asociado y para que se puedan modificar los valores del contenedor. 

Es usual el que un iterador sea creado con un constructor que lo asocie a un 
unico objeto contenedor, y que ese iterador no pueda ser asociado a otro contenedor 
diferente durante su ciclo de vida. (Los iteradores son normalemente pequenos y 
baratos, por lo que se puede crear otro facilmente). 

Con el iterador, se puede atravesar los elementos de la pila sin sacarlos de ella, 
como un puntero se mueve a traves de los elementos del array. Sin embargo, el ite¬ 
rador conoce la estructura interna de la pila y como atravesar los elementos, dando 
la sensacion de que se esta moviendo a traves de ellos como si fuera «incrementar 
un puntero», aunque sea mas complejo lo que pasa por debajo. Esta es la clave del 
iterador: Abstrae el proceso complicado de moverse de un elemento del contenedor 
al siguiente y lo convierte en algo parecido a un puntero. La meta de cada iterador 
del programa es que tengan la misma interfaz para que cualquier codigo que use un 
iterador no se preocupe de a que esta apuntando - solo se sabe que todos los itera¬ 
dores se tratan de la misma manera, por lo que no es importante a lo que apunte 
el iterador. De esta forma se puede escribir codigo mas generico. Todos los contene- 
dores y algoritmos en la Libreria Estandar de C++ se basan en este principio de los 
iteradores. 

Para ayudar a hacer las cosas mas genericas, seria agradable decir «todas las cla- 
ses contenedoras tienen una clase asociada llama da iterator», pero esto causara 
normalmente problemas de nombres. La solucion consite en anadir una clase anida- 
da para cada contenedor (en este caso, «iterator» comienza con una letra minus- 
cula para que este conforme al estilo del C++ estandar). Aqui esta ellnterlntStack 
cpp con un iterator anidado: 

//: Cl6:Nestedlterator.cpp 

// Nesting an iterator inside the container 
//{L} fibonacci 

#include "fibonacci.h" 

#include /require.h" 

#include <iostream> 

#include <string> 
using namespace std; 

class IntStack { 

enum { ssize = 100 }; 
int stack[ssize]; 
int top; 

public: 

IntStack() : top(0) {} 
void push (int i) { 

require(top < ssize, "Too many push()es"); 
stack[top++] = i; 
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int pop() { 

require(top > 0, "Too many pop()s"); 
return stack[—top]; 

} 

class iterator; 
friend class iterator; 
class iterator { 

IntStackS s; 
int index; 
public: 

iterator(IntStackS is) : s(is), index(O) {} 

// To create the "end sentinel" iterator: 
iterator(IntStackS is, bool) 

: s(is), index(s.top) {} 
int current() const { return s.stack[index]; } 

int operator++() { // Prefix 
require(index < s.top, 

"iterator moved out of range"); 
return s.stack[++index]; 

} 

int operator++(int) { // Postfix 

require(index < s.top, 

"iterator moved out of range"); 
return s.stack[index++]; 

} 

// Jump an iterator forward 

iterators operator+=(int amount) { 
require(index + amount < s.top, 

"IntStack::iterator::operator+= () " 

"tried to move out of bounds"); 
index += amount; 
return *this; 

} 

// To see if you're at the end: 

bool operator==(const iterators rv) const { 
return index == rv.index; 

} 

bool operator!=(const iterators rv) const { 
return index != rv.index; 

} 

friend ostreamS 

operator« (ostreamS os, const iterators it) { 
return os << it.current () ; 

} 

} ; 

iterator begin() { return iterator(*this); } 

// Create the "end sentinel": 

iterator end() { return iterator(*this, true);} 


int main() { 

IntStack is; 

for(int i = 0; i < 20; i++) 
is.push(fibonacci (i)); 
cout << "Traverse the whole IntStack\n"; 
IntStack :: iterator it = is.beginO; 
while (it != is.endO) 
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cout << it++ << endl; 

cout << "Traverse a portion of the IntStack\n"; 
IntStack::iterator 

start = is.begin(), end = is.begin(); 
start += 5, end += 15; 
cout << "start = " << start << endl; 
cout << "end = " << end << endl; 
while (start != end) 

cout << start+t << endl; 

} ///:~ 


Cuando se crea una clase friend anidada,hay que seguir elproceso deprimero 
declarar el nombre de la clase, despues declararla como f riend, y despues definir 
la clase. De otra forma, se confundira el compilador. 

A1 iterador se le han dado algunas vueltas de tuerca mas. La funcion miembro 
current () produce el elemento que el iterador esta seleccionando actualmente en 
el contenedor. Se puede «saltar» hacia adelante un numero arbitrario de elementos 
usando el operator+=. Tambien, se pueden ver otros dos operadores sobrecarga- 
dos: == y != que compararan un iterador con otro. Estos operadores pueden com- 
parar dos IntStack : : iterator, pero su intencion primordial es comprobar si el 
iterador esta al final de una secuencia de la misma manera que lo hacen los iterado- 
res «reales» de la Libreria Estandar de C++. La idea es que dos iteradores definan 
un rango, incluyendo el primer elemento apuntado por el primer iterador pero sin 
incluir el ultimo elemento apuntado por el segundo iterador. Por esto, si se quie- 
re mover a traves del rango definido por los dos iteradores, se dira algo como lo 
siguiente: 

while (star != end) 
cout << start++ << endl; 


Donde start y end son los dos iteradores en el rango. Note que el iterador 
end, al cual se le suele referir como el end sentinel, no es desreferenciado y nos 
avisa que estamos al final de la secuencia. Es decir, representa el que «otro sobrepasa 
el final». 

La mayoria del tiempo se querra mover a traves de la secuencia entera de un 
contenedor, por lo que el contenedor necesitara alguna forma de producir los itera¬ 
dores indicando el principio y el final de la secuencia. Aqui, como en la Standard 
C++ Library, estos iteradores se producen por las funciones miembro del contenedor 
begin () y end (). begin () usa el primer constructor de iterator que por 
defecto apunta al principio del contenedor (esto es el primer elemento que se intro- 
dujo en la pila). Sin embargo, un segundo constructor, usado por end (), es necesario 
para crear el iterador final. Estar «al final» significa apuntar a lo mas alto de la pila, 
porque t op siempre indica el siguiente espacio de la pila que este disponible pero 
sin usar. Este constructor del iterator toma un segundo argumento del tipo bool, 
lo cual es util para distinguir los dos constructores. 

De nuevo se usan los numeros Fibonacci para rellenar la IntStack en el ma¬ 
in (), y se usan iteradores para moverse completamente a traves de la IntStack 
asi como para moverse en un reducido rango de la secuencia. 

El siguiente paso, por supuesto, es hacer el codigo general transformandolo en 
un template del tipo que maneje, para que en vez ser forzado a manejar enteros se 
pueda gestionar cualquier tipo: 
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//: Cl6:IterStackTemplate.h 

// Simple stack template with nested iterator 

#ifndef ITERSTACKTEMPLATE_H 
#define ITERSTACKTEMPLATE_H 
#include /require.h" 

#include <iostream> 

template<class T, int ssize = 100> 
class StackTemplate { 

T stack[ssize]; 
int top; 

public: 

StackTemplate() : top(0) {} 

void push (const Ts i) { 

require(top < ssize, "Too many push()es"); 
stack[top++] = i; 

} 

T pop() { 

require(top > 0, "Too many pop()s"); 
return stack[—top]; 

} 

class iterator; // Declaration required 
friend class iterator; // Make it a friend 
class iterator { // Now define it 
StackTemplateS s; 
int index; 
public: 

iterator(StackTemplateS st) : s(st),index (0){} 
// To create the "end sentinel" iterator: 

iterator ( StackTemplateS st, bool) 

: s (st), index(s.top) {} 

T operator* () const { return s.stack[index];} 
T operator+t () { // Prefix form 

require(index < s.top, 

"iterator moved out of range"); 
return s.stack[++index]; 

} 

T operator++(int) { // Postfix form 
require(index < s.top, 

"iterator moved out of range"); 
return s.stack[index++] ; 

} 

// Jump an iterator forward 

iterators operator+=(int amount) { 
require(index + amount < s.top, 

" StackTemplate::iterator::operator+= () " 

"tried to move out of bounds"); 
index += amount; 
return *this; 

} 

// To see if you're at the end: 

bool operator==(const iterators rv) const { 
return index == rv.index; 

} 

bool operator!=(const iterators rv) const { 
return index != rv.index; 

} 
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friend std::ostreamS operator<<( 

std::ostreamS os, const iterators it) { 
return os << *it; 

} 

} ; 

iterator begin() { return iterator( *this) ; } 

// Create the "end sentinel": 

iterator end() { return iterator (*this, true);} 

} ; 

#endif // ITERSTACKTEMPLATE_H ///:- 


Se puede ver que la transformation de una clase regular en un template es 
razonablemente transparente. Esta aproximacion de primero crear y depurar una 
clase ordinaria, y despues transformarla en plantilla, esta generalmente considerada 
como mas sencilla que crear el template desde la nada. 

Dese cuenta que en vez de solo decir: 

friend iterator; // Hacerlo amigo 

Este codigo tiene: 

friend class iterator; // Hacerlo amigo 

Esto es importante porque el nombre «iterator» ya existe en el ambito de re¬ 
solution, por culpa de un archivo incluido. 

En vez de la funcion miembro current (), el iterator tiene un operator* 
para seleccionar el elemento actual, lo que hace que el iterator se parezca mas a 
un puntero lo cual es una practica comun. 

Aqui esta el ejemplo revisado para comprobar el template. 

// : C16 :IterStackTemplateTest.cpp 
//{L} fibonacci 

#include "fibonacci.h" 

#include "IterStackTemplate.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

int main () { 

StackTemplate<int> is; 
for(int i = 0; i < 20; i++) 
is.push(fibonacci(i)); 

// Traverse with an iterator: 

cout << "Traverse the whole StackTemplateXn"; 

StackTemplate<int>::iterator it = is.begin(); 
while (it != is.endO) 
cout << it++ << endl; 
cout << "Traverse a portionin' 1 ; 

StackTemplate<int>::iterator 

start = is.begin(), end = is.begin(); 
start += 5, end += 15; 
cout << "start = " << start << endl; 
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cout << "end = " << end << endl; 
while (start != end) 

cout << start++ << endl; 
ifstream in ( "IterStackTemplateTest.cpp"); 
assure(in, "IterStackTemplateTest.cpp"); 
string line; 

StackTemplate<string> strings; 
while (getline(in, line)) 
strings.push(line); 

StackTemplate<string>::iterator 

sb = strings.begin(), se = strings.end(); 
while (sb != se) 

cout << sb++ << endl; 

} ///:- 


El primer uso del iterador simplemente lo recorre de principio a fin (y muestra 
que el limite final funciona correctamente). En el segundo uso, se puede ver como los 
iteradores permite facilmente especificar un rango de elementos (los contenedores y 
los iteradores del Standard C++ Library usan este concepto de rangos casi en cual- 
quier parte). El sobrecargado operator+= mueve los iteradores start y end a 
posiciones que estan en el medio del rango de elementos de is, y estos elementos 
son imprimidos. Hay que resaltar, como se ve en la salida, que el elemento final no 
esta incluido en el rango, o sea que una vez llegado al elemento final (end sentinel) se 
sabe que se ha pasado el final del rango - pero no hay que desreferenciar el elemento 
final o si no se puede acabar desreferenciando un puntero nulo. (Yo he puesto un 
guardian en el StackTemplate : : iterator, pero en la Libreria Estandar de C++ 
los contenedores y los iteradores no tienen ese codigo - por motivos de eficiencia - 
por lo que hay que prestar a tendon). 

Por ultimo para verificar que el StackTemplate funciona con objetos clase, se 
instancia uno para strings y se rellena con lineas del codigo fuente, las cuales son 
posteriormente imprimidas en pantalla. 


16.7.1. Stack con iteradores 

Podemos repetir el proceso con la clase de tamano dinamico Stack que ha sido 
usada como un ejemplo a lo largo de todo el libro. Aqui esta la clase Stack con un 
iterador anidado en todo el medio: 

//: Cl6:TStack2 .h 

// Templatized Stack with nested iterator 

#ifndef TSTACK2_H 
#define TSTACK2_H 

template<class T> class Stack { 
struct Link { 

T* data; 

Link* next; 

Link(T* dat. Link* nxt) 

: data(dat), next(nxt) {} 

}* head; 

public: 

Stack() : head(0) {} 

-Stack(); 



'Volumenl" — 2012/1/12 — 13:52 — page 508 — #546 


Capitulo 16. Introduction a las Plantillas 


void push(T* dat) { 

head = new Link(dat, head); 

} 

T* peek() const { 

return head ? head->data : 0; 

} 

T * pop(); 

// Nested iterator class: 

class iterator; // Declaration required 
friend class iterator; // Make it a friend 
class iterator { // Now define it 

Stack::Link* p; 

public: 

iterator (const Stack<T>S tl) : p(tl.head) {} 

// Copy-constructor: 

iterator (const iterators tl) : p(tl.p) {} 

// The end sentinel iterator: 
iterator () : p (0) { } 

// operator++ returns boolean indicating end: 

bool operator!!() { 

if (p->next ) 
p = p->next; 

else p = 0; // Indicates end of list 

return bool (p) ; 

} 

bool operator!!(int) { return operator!!(); } 

T* current () const { 
if(!p) return 0; 
return p->data; 

} 

// Pointer dereference operator: 

T* operator->() const { 

require(p != 0, 

"PStack::iterator::operator->returns 0") ; 
return current () ; 

} 

T* operator*() const { return current (); } 

// bool conversion for conditional test: 

operator bool() const { return bool(p); } 

// Comparison to test for end: 

bool operator==(const iterators) const { 
return p == 0 ; 

} 

bool operator!=(const iterators) const { 
return p != 0 ; 

} 

} ; 

iterator begin () const { 
return iterator (*this); 

} 

iterator end () const { return iterator (); } 


templatecclass T> Stack<T>::-Stack() { 

while (head) 

delete pop (); 

} 


508 




'Volumenl" — 2012/1/12 — 13:52 — page 509 — #547 



16.7. Introduction a los iteradores 


template<class T> T* Stack<T>::pop() { 

if (head == 0) return 0; 

T* result = head->data; 

Link* oldHead = head; 
head = head->next; 
delete oldHead; 
return result; 

} 

#endif // TSTACK2_H ///:- 


Hay que hacer notar que la clase ha sido cambiada para soportar la posesion, 
que funciona ahora debido a que la clase conoce ahora el tipo exacto (o al menos 
el tipo base, que funciona asumiendo que son usados los destructores virtuales). La 
opcion por defecto es que el contenedor destruya sus objetos pero nosotros somos 
responsables de los objetos a los que se haga pop ( ). 

El iterador es simple, y fisicamente muy pequeno - el tamano de un unico pun- 
tero. Cuando se crea un iterator, se inicializa a la cabeza de la lista enlazada, y 
solo puede ser incrementado avanzando a traves de la lista. Si se quiere empezar 
desde el principio, hay que crear un nuevo iterador, y si se quiere recordar un punto 
de la lista, hay que crear un nuevo iterador a partir del iterador existente que esta 
apuntando a ese elemento (usando el constructor de copia del iterador). 

Para llamar a funciones del objeto referenciado por el iterador, se puede usar 
la funcion current (), el operator*, o la desreferencia de puntero operator — 
> (un elemento comun en los iteradores). La ultima tiene una implementation que 
parece identica a current () debido a que devuelve un puntero al objeto actual, 
pero es diferente porque el operador desreferencia del puntero realiza niveles extra 
de desreferenciacion (ver Capitulo 12). 

La clase iterator sigue el formato que se vio en el ejemplo anterior, clas- 
s iterator esta anidada dentro de la clase contenedora, contiene constructores 
para crear un iterador que apunta a un elemento en el contenedor y un iterador 
«marcador de final», y la clase contenedora tiene los metodos begin () y end (- 
) para producir estos iteradores. (Cuando aprenda mas de la Libreria Estandar de 
C++, vera que los nombres iterator, begin () y end () que se usan aqui tienen 
correspondecia en las clases contenedoras. Al final de este capitulo, se vera que esto 
permite manejar estas clases contenedoras como si fueran clases de la STL). 

La implementation completa se encuentra en el archivo cabecera, por lo que no 
existe un archivo cpp separado. Aqui tenemos un pequeno test que usa el iterador. 

//: Cl6:TStack2Test.cpp 

#include "TStack2.h" 

#include /require.h" 

#include <iostream> 

#include <fstream> 

#include <string> 
using namespace std; 

int main() { 

ifstream file("TStack2Test.cpp"); 

assure (file, "TStack2Test.cpp"); 

Stack<string> textlines; 

// Read file and store lines in the Stack: 

string line; 
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while (getline(file, line)) 

textlines.push (new string(line)); 
int i = 0; 

// Use iterator to print lines from the list: 
Stack<string>::iterator it = textlines.begin (); 
Stack<string>::iterator* it2 = 0; 
while(it != textlines.end()) { 

cout << it->c_str() << endl; 
it++; 

if (++i == 10) // Remember 10th line 

it2 = new Stack<string>::iterator(it); 

} 

cout << (*it2)->c_str() << endl; 
delete it2; 

} ///■- 


Una pila Stack es instanciada para gestionar objetos string y se rellena con 
lineas de un fichero. Entonces se crea un iterador y se usa para moverse a traves 
de la secuencia. La decima linea es recordada mediante un segundo iterador creado 
con el constructor de copia del primero; posteriormente esta linea es imprimida y el 
iterador - crado dinamicamente - es destruido. Aqui la creacion dinamica de objetos 
es usada para controlar la vida del objeto. 


16.7.2. PStash con iteradores 

Para la mayoria de los contenedores tiene sentido tener un iterador. Aqui tene- 
mos un iterador anadido a la clase PStash: 

//: Cl6:TPStash2.h 

// Templatized PStash with nested iterator 

#ifndef TPSTASH2_H 
#define TPSTASH2_H 

#include "../require.h" 

#include <cstdlib> 

template<class T, int incr = 20> 
class PStash { 
int quantity; 
int next; 

T** storage; 

void inflate (int increase = incr); 

public: 

PStash() : quantity(0), storage(0), next(0) {} 

-PStash (); 

int add(T* element); 

T* operator!](int index) const; 

T* remove (int index); 

int count () const { return next; } 

// Nested iterator class: 

class iterator; // Declaration required 
friend class iterator; // Make it a friend 
class iterator { // Now define it 

PStashS ps; 
int index; 

public: 
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iterator(PStashS pStash) 

: ps(pStash), index(0) {} 

// To create the end sentinel: 
iterator(PStashS pStash, bool) 

: ps(pStash), index(ps.next) {} 

// Copy-constructor: 
iterator (const iterators rv) 

: ps(rv.ps), index(rv.index) {} 
iterators operator=(const iterators rv) { 
ps = rv.ps; 
index = rv.index; 
return *this; 

} 

iterators operator++() { 

require(++index <= ps.next, 

"PStash::iterator::operator++ " 

"moves index out of bounds"); 

return *this; 

} 

iterators operator++(int) { 
return operator++() ; 

} 

iterators operator—() { 

require(—index >= 0, 

"PStash::iterator::operator— " 

"moves index out of bounds"); 

return *this; 

} 

iterators operator—(int) { 
return operator—(); 

} 

// Jump interator forward or backward: 

iterators operator+=(int amount) § 
require(index + amount < ps.next SS 
index + amount >= 0, 

"PStash::iterator::operator+= " 

"attempt to index out of bounds"); 
index += amount; 
return *this; 

} 

iterators operator-=(int amount) { 
require(index - amount < ps.next SS 
index - amount >= 0, 

"PStash::iterator::operator-= " 

"attempt to index out of bounds"); 
index -= amount; 
return *this; 

} 

// Create a new iterator that's moved forward 

iterator operator!(int amount) const { 
iterator ret(*this); 

ret += amount; // op+= does bounds check 

return ret ; 

} 

T* current () const { 

return ps.storage[index] ; 

} 

T* operator* () const { return current(); } 
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T* operator->() const { 

require(ps.storage[index] != 0, 

"PStash::iterator::operator->returns 0"); 
return current() ; 

} 

// Remove the current element: 

T* remove () { 

return ps.remove(index); 

} 

// Comparison tests for end: 

bool operator==(const iterators rv) const { 
return index == rv.index; 

} 

bool operator!=(const iterators rv) const { 
return index != rv.index; 

} 

} ; 

iterator begin() { return iterator( *this) ; } 

iterator end() { return iterator (*this, true);} 


// Destruction of contained objects: 

templatecclass T, int incr> 

PStash<T, incr>::-PStash() { 

for(int i = 0; i < next; i++) { 

delete storage[i]; // Null pointers OK 
storage[i] =0; // Just to be safe 

} 

delete []storage; 


templatecclass T, int incr> 
int PStashcT, incr>::add(T* element) { 
if (next >= quantity) 
inflate(); 

storage[next++] = element; 
return (next - 1); // Index number 

} 


templatecclass T, int incr> inline 
T* PStashcT, incr>:: operator[](int index) const { 
require(index >= 0, 

"PStash::operator[] index negative"); 
if (index >= next) 

return 0; //To indicate the end 
require(storage[index] != 0, 

"PStash::operator[] returned null pointer"); 
return storage[index] ; 


templatecclass T, int incr> 

T* PStashcT, incr>::remove (int index) { 

// operator[] performs validity checks: 

T* v = operator}] (index); 

// "Remove" the pointer: 

storage[index] = 0; 

return v; 
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template<class T, int incr> 

void PStash<T, incr>::inflate (int increase) { 
const int tsz = sizeof(T*); 

T** st = new T*[quantity + increase]; 

memset(st, 0, (quantity + increase) * tsz); 

memcpy(st, storage, quantity * tsz); 

quantity += increase; 

delete []storage; // Old storage 

storage = st; // Point to new memory 

} 

#endif // TPSTASH2_H ///:- 


La mayoria de este archivo es un traduccion practicamente directa del anterior 
PStash y el iterador anidado dentro de un template. Esta vez, sin embargo, el 
operador devuelve referencias al iterador actual, la cual es una aproximacion mas 
tipica y flexible. 

El destructor llama a delete para todos los punteros que contiene, y como el 
tipo es obtenido de la plantilla, se ejecutara la destruccion adecuada. Hay que estar 
precavido que si el contenedor controla punteros al tipo de la clase base, este tipo 
debe tener un destructor virtual para asegurar un limpiado adecuado de los 
objetos derivados que hayan usado un upcast cuando se los alojo en el contenedor. 

El PStash: : iterator mantiene el modelo de engancharse a un unico obje- 
to contenedor durante su ciclo de vida. Ademas, el constructor de copia permite 
crear un nuevo iterador que apunte a la misma posicion del iterador desde el que se 
le creo, creando de esta manera un marcador dentro del contenedor. Las funciones 
miembro operator+= y el operator-= permiten mover un iterador un numero 
de posiciones, mientras se respeten los limites del contenedor. Los operadores sobre- 
cargados de incremento y decremento mueven el iterador una posicion. El opera¬ 
tor! produce un nuevo iterador que se mueve adelante la cantidad anadida. Como 
en el ejemplo anterior, los operadores de desreferencia de punteros son usados para 
manejar el elemento al que el iterador esta referenciando, y remove ( ) destruye el 
objeto actual llamando al remove ( ) del contenedor. 

Se usa la misma clase de codigo de antes para crear el marcador final: un segundo 
constructor, la funcion miembro del contenedor end (), y el operator== y ope¬ 
rator != para comparaciones. 

El siguiente ejemplo crea y comprueba dos diferentes clases de objetos Stash, 
uno para una nueva clase llama da Int que anuncia su construction y destruccion y 
otra que gestiona objetos string de la libreria Estandar. 

//: Cl6:TPStash2Test.cpp 

#include "TPStash2.h" 

#include /require.h" 

#include <iostream> 

#include <vector> 

#include <string> 
using namespace std; 

class Int { 
int i; 
public: 

Int (int ii = 0) : i(ii) { 
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cout << ">" << i << ' '; 

i 

~Int () { cout << << i << ' ' ; } 

operator int() const { return i; } 
friend ostreamS 

operator« (ostreamS os, const Int& x) { 
return os << "Int: " << x.i; 

} 

friend ostreamS 

operator« (ostreamS os, const Int* x) { 
return os << "Int: " << x->i; 



int main () { 

{ // To force destructor call 

PStash<Int> ints; 
for(int i = 0; i < 30; i++) 
ints.add(new Int(i)); 
cout << endl; 

PStash<Int>::iterator it = ints.begin(); 
it += 5; 

PStash<Int>::iterator it2 = it + 10; 
for(; it != it2; it++) 

delete it.remove(); // Default removal 
cout << endl; 

for(it = ints.begin ();it != ints.end();it++) 
if(*it) // Remove() causes "holes" 
cout << *it << endl; 

} // "ints" destructor called here 

cout << "\n-\n"; 

ifstream in("TPStash2Test.cpp"); 
assure(in, "TPStash2Test.cpp"); 

// Instantiate for String: 

PStash<string> strings; 
string line; 

while(getline(in, line)) 

strings.add(new string(line)); 

PStash<string>::iterator sit = strings.begin() ; 
for(; sit != strings.end(); sit++) 
cout << **sit << endl; 
sit = strings.begin(); 
int n = 26; 
sit += n; 

for(; sit != strings.end(); sit++) 

cout << n++ << ": " << **sit << endl; 

} |//:~ 


Por conveniencia Int tiene asociado un ostream operator« para Int& y 
Int*. 

El primer bloque de codigo en main () esta rodeado de Haves para forzar la des¬ 
truction de PStash<Int> que produce un limpiado automatico por este destructor. 
Unos cuantos elementos son sacados y borrados a mano para mostrar que P St ash 
limpia el resto. 
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Para ambas instancias de PStash, se crea un iterador y se usa para moverse a 
traves del contenedor. Note la elegancia generada por el uso de estos constructores; 
no hay que preocuparse por los detalles de implementation de usar un array. Se 
le dice al contenedor y al iterador que hacer y no como hacerlo. Esto produce una 
solucion mas sencilla de conceptualizar, construir y modificar. 


16.8. Por que usar iteradores 

Hasta ahora se han visto los mecanismos de los iteradores, pero entender el por 
que son tan importantes necesita un ejemplo mas complejo. 

Es normal ver el polimorfismo, la creation dinamica de objetos, y los contenedo- 
res en un programa orientado a objetos real. Los contendores y la creacion dinamica 
de objetos resuelven el problema de no saber cuantos o que tipo de objetos se nece- 
sitaran. Y si el contenedor esta configurado para manejar punteros a la clase base, 
cada vez que se ponga un puntero a una clase derivada hay un upcast (con los be- 
neficios que conlleva de claridad de codigo y extensibilidad). Como codigo del final 
del Volumen 1, este ejemplo reune varios aspectos de todo lo que se ha aprendido - 
si es capaz de seguir este ejemplo, entonces esta preparado para el Volumen 2. 

Suponga que esta creando un programa que permite al usuario editar y producir 
diferentes clases de dibujos. Cada dibujo es un objeto que contiene una coleccion de 
objetos Shape: 

// : Cl6:Shape.h 

#ifndef SHAPE_H 
#define SHAPE_H 
#include <iostream> 

#include <string> 

class Shape { 
public: 

virtual void draw() = 0; 
virtual void erase() = 0; 
virtual -Shape() {} 

} ; 


class Circle : public Shape { 
public: 

Circle () {} 

-Circle () { std::cout << "Circle::-CircleXn"; } 

void draw() { std::cout << "Circle::draw\n";} 

void erase () { std::cout << "Circle::erase\n";} 


class Square : public Shape { 
public: 

Square() {} 

-Square() { std::cout << "Square::-SquareXn"; } 

void draw() { std::cout << "Square::draw\n";} 

void erased { std::cout << "Square::erase\n";} 


class Line : public Shape { 
public: 

Lined {} 
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~Line() { std::cout << "Line::~Line\n"; } 

void draw() { std::cout << "Line::draw\n";} 

void erase() { std::cout << "Line::erase\n";} 

} ; 

#endif // SHAPE_H ///:- 


Se usa la estructura clasica de las funciones virtuales en la clase base que son 
sobreescritas en la clase derivada. Hay que resaltar que la clase Shape incluye un 
destructor virtual, algo que se deberia anadir automaticamente a cualquier clase con 
funciones virtuales. Si un contenedor maneja punteros o referencias a objetos S- 
hape, entonces cuando los destructores virtuales sean llamados para estos objetos 
todo sera correctamente limpiado. 

Cada tipo diferente de dibujo en el siguiente ejemplo hace uso de una plantilla 
de clase contenedora diferente: el PStash y el Stack que han sido definido en 
este capitulo, y la clase vector de la Libreria Estandar de C++. El «uso» de los 
contenedores es extremadamente simple, y en general la herencia no es la mejor 
aproximacion (composicion puede tener mas sentido), pero en este caso la herencia 
es una aproximacion mas simple. 

//: Cl6:Drawing.cpp 

#include <vector> // Uses Standard vector too! 

#include "TPStash2.h" 

#include "TStack2.h" 

#include "Shape.h" 
using namespace std; 

//A Drawing is primarily a container of Shapes: 

class Drawing : public PStash<Shape> { 

public: 

-Drawing() { cout << "-Drawing" << endl; } 

} ; 

//A Plan is a different container of Shapes: 

class Plan : public Stack<Shape> { 

public: 

~Plan() { cout << "-Plan" << endl; } 

} ; 

//A Schematic is a different container of Shapes: 
class Schematic : public vector<Shape*> { 

public: 

-Schematic() { cout << "-Schematic" << endl; } 

} ; 

//A function template: 

templatecclass Iter> 

void drawAll(Iter start, Iter end) { 
while (start != end) { 

(*start)->draw() ; 
start++; 

} 

} 

int main () { 

// Each type of container has 
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// a different interface: 

Drawing d; 
d.add(new Circle); 
d.add(new Square); 
d.add(new Line); 

Plan p; 

p.push (new Line); 
p.push (new Square); 
p.push (new Circle); 

Schematic s; 

s.push_back (new Square); 
s.push_back (new Circle); 
s.push_back (new Line); 

Shape* sarray[] = { 

new Circle, new Square, new Line 

} ; 

// The iterators and the template function 

// allow them to be treated generically: 

cout << "Drawing d:" << endl; 

drawAll (d.begin () , d.endO); 

cout << "Plan p:" << endl; 

drawAll (p.begin () , p.endO); 

cout << "Schematic s:" << endl; 

drawAll (s . begin () , s.endO); 

cout << "Array sarray:" << endl; 

// Even works with array pointers: 
drawAll(sarray, 

sarray + sizeof (sarray) /sizeof (*sarray)); 
cout << "End of main" << endl; 

} ///:- 


Los distintos tipos de contenedores manejan punteros a Shape y punteros a 
objetos de clases derivadas de Shape. Sin embargo, debido al polimorfismo, cuando 
se llama a las funcione virtuales ocurre el comportamiento adecuado. 

Note que sarray, el array de Shape*, puede ser recorrido como un contenedor. 


16.8.1. Plantillas Funcion 

En drawAll () se ve algo nuevo. En este capitulo, unicamente hemos estado 
usando plantillas de clases, las cuales pueden instanciar nuevas clases basadas en uno 
o mas parametros de tipo. Sin embargo, se puede crear plantillas de funcion, las cua¬ 
les crean nuevas funciones basadas en parametros de tipo. La razon para crear una 
plantilla de funcion es la misma por la cual se crea una plantilla de clase: intentar 
crear codigo mas generico, y se hace retrasando la especificacion de uno o mas tipos. 
Se quiere decir que estos parametros de tipos soportan ciertas operaciones, no que 
tipos exactos son. 

Se puede pensar sobre la plantilla funcion drawAl 1 () como si fuera un algorit- 
mo (y asi es como se llaman la mayoria de las plantillas de funcion de la STL). Solo 
dice como hacer algo dado unos iteradores que describen un rango de elementos, 
mientras que estos iteradores pueden ser desreferenciados, incrementados, y corn- 
parados. Estos son exactamente la clase de iteradores que hemos estado desarrollan- 
do en este capitulo, y tambien - y no por casualidad - la clase de iteradores que son 
producidos por los contenedores de la Libreria Estandar de C++, evidenciado por el 
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uso de vector en este ejemplo. 

Ademas nos gustaria que drawAll () fuera un algoritmo generico, para que los 
contenedores pudieran ser de cualquier tipo y que no se tuviera que escribir una 
nueva version del algoritmo para cada tipo diferente del contenedor. Aqui es donde 
las plantillas de funciones son esenciales, porque automaticamente generan el codi- 
go especifico para cada tipo de contenedor diferente. Pero sin la indireccion extra 
proporcionada por los iteradores, estas generalizaciones no serian posibles. Este es 
el motivo por el que los iteradores son importantes; nos permiten escribir codigo de 
proposito general que involucra a contenedores sin conocer la estructura subyacente 
del contenedor. (Note que los iteradores de C++ y los algoritmos genericos requieren 
plantillas de funciones). 

Se puede ver el alcance de esto en el main (), ya que drawAll () funciona sin 
cambiar cada uno de los diferentes tipos de contenedores. E incluso mas interesante, 
drawAll () tambien funciona con punteros al principio y al final del array sarr- 
ay. Esta habilidad para tratar arrays como contenedores esta integrada en el diseno 
de la Libreria Estandar de C++, cuyos algoritmos se parecen mucho a drawAll (). 

Debido a que las plantillas de clases contenedoras estan raramente sujetas a la 
herencia y al upcast se ven como clases «ordinarias», casi nunca se veran funcio¬ 
nes virtuales en clases contenedoras. La reutilizacion de las clases contenedoras esta 
implementado mediante plantillas, no mediante herencia. 


16.9. Resumen 

Las clases contenedoras son una parte esencial de la programacion orientada a 
objetos. Son otro modo de simplificar y ocultar los detalles de un programa y de 
acelerar el proceso de desarrollo del programa. Ademas, proporcionan un gran nivel 
de seguridad y flexibilidad reemplazando los anticuados arrays y las relativamente 
toscas tecnicas de estructuras que se pueden encontrar en C. 

Como el programador cliente necesita contenedores, es esencial que sean faciles 
de usar. Aqui es donde entran los templates. Con las plantillas la sintaxis para el 
reciclaje del codigo fuente (al contrario del reciclaje del codigo objeto que proporcio- 
na la herencia y la composicion) se vuelve lo suficientemente trivial para el usuario 
novel. De hecho, la reutilizacion de codigo con plantillas es notablemente mas facil 
que la herencia y el polimorfismo. 

Aunque se ha aprendido como crear contenedores y clases iteradoras en este li- 
bro, en la practica es mucho mas util aprender los contenedores e iteradores que 
contiene la Libreria Estandar de C++, ya que se puede esperar encontrarlas en cual¬ 
quier compilador. Como se vera en el Volumen 2 de este libro (que se puede bajar 
de www.BruceEckel.com, los contenedores y algoritmos de la STL colmaran virtual- 
mente sus necesidades por lo que no tendra que crear otras nuevas. 

Las caracteristicas que implica el diseno con clases contenedoras han sido intro- 
ducidas a lo largo de todo el capitulo, pero hay que resaltar que van mucho mas 
alia. Una libreria de clases contenedoras mas complicada deberia cubrir todo tipo 
de caracteristicas adicionales, como la multitarea, la persistencia y la recoleccion de 
basura. 
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16.10. Ejercicios 

Las soluciones a los ejercicios se pueden encontrar en el documento electroni- 
co titulado «The Thinking in C++ Annotated Solution Guide», disponible por poco 
dinero en www.BruceEckel.com. 

1. Implemente la jerarquia de herencia del diagrama de OShape de este capitu- 
lo. 

2. Modifique el resultado del Ejercicio 1 del capitulo 15 para usar la Stack y el 
iterator enTStack2.h en vez de un array de punteros a Shape. Anada 
destructores a la jerarquia de clases para que se pueda ver que los objetos Sh¬ 
ape han sido destruidos cuando la Stack se sale del ambito. 

3. Modifique TPStash. h para que el valor de incremento usado por inf 1 at - 
e () pueda ser cambiado durante la vida de un objeto contenedor particular. 

4. Modifique TPStash. h para que el valor de incremento usado por inflate- 
() automaticamente cambie de tamano para que reduzca el numero de veces 
que debe ser llamado. Por ejemplo, cada vez que se llama podria doblar el valor 
de incremento para su uso en la siguiente llamada. Demuestre la funcionalidad 
mostrando cada vez que se llama ainflate (), y escriba codigo de prueba en 
main (). 

5. Convierta en plantilla la funcion de fibonacci () con los tipos que puede 
producir (puede generar long, float, etc. en vez de solo int). 

6. Usar el vector de la STL como implementacion subyacente, para crear una 
platilla Set que acepte solo uno de cada tipo de objeto que se aloje en el. 
Cree un iterador anidado que soporte el concepto de "marcador final" de este 
capitulo. Escriba codigo de prueba para el Set en el main (), y entonces sus- 
tituyalo por la plantilla set de la STL para comprobar que el comportamiento 
es correcto. 

7. Modifique AutoCounter . h para que pueda ser usado como un objeto miem- 
bro dentro de cualquier clase cuya creacion y destruccion quiera comprobar. 
Anada un miembro string para que contenga el nombre de la clase. Comprue- 
be esta herramienta dentro una clase suya. 

8. Cree una version de Owner Stack . h que use un vector de la Libreria Es- 
tandar de C++ como su implementacion subyacente. Sera necesario conocer 
algunas de las funciones miembro de vector para poder hacerlo (solo hay 
que mirar en el archivo cabecera <vector>). 

9. Modifique ValueStack.h para que pueda expandirse dinamicamente se- 
gun se introduzcan mas objetos y se quede sinespacio. Cambie ValueStackTest. 
cpp para comprobar su nueva funcionalidad. 

10. Repita el ejercicio 9 pero use el vector de la STL como la implementacion 
interna de ValueStack. Note lo sencillo que es. 

11. Modifique ValueStackTest. cpp para que use un vector de la STL en 
vez de un Stack en el main () . Dese cuenta del comportamiento en tiempo 
de ejecucion: ^Se genera un grupo de objetos por defecto cuando se crea el 
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12. Modifique TStack2 . h para que use un vector de la STL. Asegurese de 
que no cambia la interfaz, para que TStack2Test. cpp funcione sin cam- 
biarse. 

13. Repita el Ejercicio 12 usando una stack de la Libreria Estandar de C++ en 
vez de un vector. 

14. Modifique TPStash2 . h para que use un vector delaSTLcomosuimple- 
mentacion interna. Asegurese que no cambia la interfaz, por lo que TPStash2Test. 
cpp funciona sin modificarse. 

15. En IterlntStack . cpp, modifique IntStacklter para darle un construc¬ 
tor de «marcador final», y anada el operator== y el operator ! =. En el m- 
ain () , use un iterador para mo verse a traves de los elementos del contenedor 
hasta que se encuentre el marcador. 

16. Use TStack2 . h, TPSTash2 . h, y Shape . h, instancie los contenedores PSt- 
ash y Stack para que contenga Shape*, rellene cada uno con punteros a 
Shape, entonces use iteradores para moverse a traves de cada contenedor y 
llame a draw () para cada objeto. 

17. Cree una plantilla en la clase Int para que pueda alojar cualquier tipo de objetos 
(Sientase libre de cambiar el nombre de la clase a algo mas apropiado). 

18. Cree una plantilla de la clase Int Array en IostreamOperatorOver loading . 

cpp del capitulo 12, introduzca en plantilla ambos tipos de objetos que estan 
contenidos y el tamano del array interno 

19. Convierta Ob jContainer en NestedSmartPointer . cpp del Capitulo 12 
en una plantilla. Compruebelo con dos clases diferentes. 

20. Modifique C15 : OStack . h y C15 : OStackTest . cpp consiguiendo que c- 
lass Stack pueda tener multiple herencia automaticamente de la clase con- 
tenida y de Object. La Stack contenida debe aceptar y producir solo pun¬ 
teros del tipo contenido. 

21. Repita el ejercicio 20 usando vector en vez de Stack. 

22. Herede una clase StringVector de vector<void> y redefina las funcio- 
nes miembro push_back () y el operator [ ] para que acepten y produz- 
can unicamente string”' (y realizen el moldeado adecuado). Ahora creee una 
plantilla que haga automaticamente lo mismo a una clase contenedora para 
punteros de cualquier tipo. Esta tecnica es a menudo usada para reducir el 
codigo producido por muchas instanciaciones de templates. 

23. En TPStash2 . h, anada y compruebe un operator- para PStash :: iter¬ 
ator, siguiendo la logica de operator+. 

24. En Drawing, cpp, anada y compruebe una plantilla de funcion que llame a 
funciones miembro erase ( ) . 

25. (Avanzado) Modifique la clase Stack enTStack2.h para permitir una gra- 
nularidad de la propiedad: Anada una bandera para cada enlace indicando si el 
enlace posee el objeto al que apunta, y de soporte a esta information la funcion 
push () y en el destructor. Anada funciones miembro para leer y cambiar la 
propiedad de cada enlace. 
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26. (Avanzado) Modifique PointerToMemberOperator. cpp del Capitulo 12 
para que la FunctionOb ject y el operator->* sean convertidos en plan- 
tillas para que funcionen con cualquier tipo de retorno (para operator->*, 
tendra que usar plantillas miembro descritas en el Volumen 2). Anada soporte y 
compruebe para cero, uno y dos argumentos en las funciones miembro Dog. 
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A: Estilo de codification 

Este apendice no trata sobre indentation o colocation de paren- 
tesis y llaves, aunque si que se menciona. Trata sobre las directrices 
generates que se usan en este libro para la organization de los lista- 
dos de codigo. 

Aunque muchas de estas cuestiones se han tratado a lo largo del libro, este apen¬ 
dice aparece al final de manera que se puede asumir que cada tema es FIXME:juego 
limpio, y si no entiende algo puede buscar en la seccion correspondiente. 

Todas las decisiones sobre estilo de codificacion en este libro han sido conside- 
radas y ejectuadas deliberadamente, a veces a lo largo de periodos de anos. Por su- 
puesto, cada uno tiene sus razones para organizar el codigo en el modo en que lo 
hace, y yo simplemente intento explicarle como llegue a tomar mi postura y las res- 
tricciones y factores del entorno que me llevaron a tomar esas decisiones. 


A.l. General 

En el texto de este libro, los identificadores (funciones, variables, y nombres de 
clases) aparecen en negrita. Muchas palabras reservadas tambien son negritas, ex- 
ceptuando aquellas que se usan tan a menudo que escribirlas en negrita puede re- 
sultar tedioso, como «class» o «virtual». 

Utilizo un estilo de codificacion particular para los ejemplos de este libro. Se 
desarrollo a lo largo de varios anos, y se inspire parcialmente en el estilo de Bjar- 
ne Stroustrup en el The C++ Programming Language 1 original. El asunto del estilo de 
codificacion es ideal para horas de acalorado debate, asi que solo dire que no trato 
de dictar el estilo correcto a traves de mis ejemplos; tengo mis propios motivos para 
usar el estilo que uso. Como C++ es un lenguaje de formato libre, cada uno puede 
continuar usando el estilo que le resulte mas comodo. 

Dicho esto, si hare hincapie en que es importante tener un estilo consistente den- 
tro de un proyecto. Si busca en Internet, encontrara un buen numero de herramientas 
que se pueden utilizar para reformatear todo el codigo de un proyecto para conse- 
guir esa valiosa consistencia. 

Los programas de este libro son ficheros extraidos automaticamentente del texto 
del libro, lo que permite que se puedan probar para asegurar que funcionan co- 
rrectamente 2 . De ese modo, el codigo mostrado en el libro deberia funcionar sin 

1 FIXME:Ibid. 

2 (N. de T.) Se refiere al libro original. En esta traduction, los programas son ficheros externos inclui- 
dos en el texto. 
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errores cuando se compile con una implementacion conforme al Estandar C++ (no 
todos los compiladores soportan todas las caracterlsticas del lenguaje). Las senten¬ 
ces que deberian causar errores de compilation estan comentadas con / / ! de mo- 
do que se pueden descubrir y probar facilmente de modo automatico. Los erro¬ 
res descubiertos por el autor apareceran primero en la version electronica del libro 
(www.BruceEckel.com) y despues en las actualizaciones del libro. 

Uno de los estandares de este libro es que todos los programas compilaran y enla- 
zaran sin errores (aunque a veces causaran advertencias). Algunos de los programas, 
que demuestran solo un ejemplo de codificacion y no representan programas com¬ 
pletes, tendran funciones main () vacias, como esta: 

int main () { } 


Esto permite que se pueda enlazar el programa sin errores. 

El estandar para main () es retornar un int, pero C++ Estandar estipula que si 
no hay una sentencia return en main (), el compilador generara automaticamente 
codigo para return 0. Esta option (no poner un return en main ()) se usa en el 
libro (algunos compiladores producen advertencias sobre ello, pero es porque no son 
conformes con C++ Estandar). 


A.2. Nombres de fichero 

En C, es tradition nombrar a los ficheros de cabecera (que contienen las decla- 
raciones) con una extension . h y a los ficheros de implementacion (que generan 
alojamiento en memoria y codigo) con una extension . c. C++ supuso una evolu¬ 
tion. Primero fue desarrollado en Unix, donde el sistema operativo distingue entre 
mayusculas y minusculas para nombres de ficheros. Los nombres originales para 
los ficheros simplemente se pusieron en mayuscula: . H y . C. Esto, por supuesto, no 
funcionaba en sistemas operativos que no distinguen entre mayusculas y minuscu¬ 
las como DOS. Los vendedores de C++ para DOS usaban extensiones hxx y exx, o 
hpp y cpp. Despues, alguien se dio cuenta que la unica razon por la que se puede 
necesitar un extension diferente es que el compilador no puede determinar si debe 
compilarlo como C o C++. Como el compilador nunca compila ficheros de cabece¬ 
ra directamente, solo el fichero de implementacion necesita una distincion. Ahora, 
en practicamente todos los sistemas, la costumbre es usar cpp para los ficheros de 
implementacion y . h para los ficheros de cabecera. Frjese que cuando se incluye un 
fichero de cabecera C++, se usa la option de no poner extension al nombre del fiche¬ 
ro, por ejemplo: #include <iostream> 


A.3. Marcas comentadas de inicio y fin 

Un tema muy importante en este libro es que todo el codigo que puede ver en 
el libro ha si do sido verificado (con al menos un compilador). Esto se consigue ex- 
trayendo automaticamente los listados del libro. Para facilitar esta tarea, todos los 
listados de codigo susceptibles de ser compilados (al contrario que los fragmentos, 
que hay pocos) tienen unas marcas comentadas al principio y al final. Estas marcas 
las usa la herramienta de extraction de codigo ExtractCode. cpp del Volumen 2 
de este libro (y que se puede encontrar en el sitio web www.BruceEckel.com) para 
extraer cada listado de codigo a partir de la version en texto piano ASCII de este 
libro. 
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La marca de fin de listado simplemente le indica a ExtractCode . cpp que ese 
es el final del listado, pero la marca de comienzo incluye informacion sobre el sub- 
directorio al que corresponde el fichero (normalmente organizado por capitulos, asi 
que si corresponde al Capitulo 8 deberia tener una etiqueta como CO8), seguido de 
dos puntos y el no mb re del fichero. 

Como ExtractCode . cpp tambien crea un makefile para cada subdirectorio, 
la informacion de como construir el programa y la linea de comando que se debe 
usar para probarlo tambien se incorpora a los listados. Si un programa es autonomo 
(no necesita ser enlazado con nada mas) no tiene informacion extra. Esto tambien es 
cierto para los ficheros de cabecera. Sin embargo, si no contiene un main () y necesita 
enlazarse con algun otro, aparece un {0} despues del no mb re del fichero. Si ese 
listado es el programa principal pero necesita ser enlazado con otros componentes, 
hay una linea adicional que comienza con / / {L} y contimia con el nombre de todos 
los ficheros con los que debe enlazarse (sin extensiones, dado que puede variar entre 
plataformas). 

Puede encontrar ejemplos a lo largo de todo el libro. 

Cuando un fichero debe extraerse sin que las marcas de inicio y fin deban incluir- 
se en el fichero extraido (por ejemplo, si es un fichero con datos para una prueba) la 
marca de inicio va seguida de un '!'. 


A.4. Parentesis, llaves e indentacion 

Habra notado que el estilo de este libro es diferente a la mayoria de los estilos 
C tradicionales. Por supuesto, cualquiera puede pensar que su propio estilo es mas 
racional. Sin embargo, el estilo que se emplea aqui tiene una logica mas simple, que 
se presentara mezclada con las de otros estilos desarrollados. 

El estilo esta motivado por una cosa: la presentacion, tanto impresa como en un 
seminario. Quiza sus necesidades sean diferentes porque no realiza muchas presen- 
taciones. Sin embargo, el codigo real se lee muchas mas veces de las que se escribe, 
y por eso deberia ser facil de leer. Mis dos criterios mas importantes son la «esca- 
neabilidad» (que se refiere a la facilidad con la que el lector puede comprender el 
significado de una unica linea) y el numero de lrneas que caben en una pagina. Lo 
segundo puede sonar gracioso, pero cuando uno da una charla, distrae mucho a la 
audiencia que el ponente tenga que avanzar y retroceder diapositivas, y solo unas 
pocas lineas de mas puede provocar este efecto. 

Todo el mundo parece estar de acuerdo en que el codigo que se pone dentro de 
llaves debe estar indentado. En lo que la gente no esta de acuerdo - y es el sitio donde 
mas inconsistencia tienen los estilos - es: ^Donde debe ir la Have de apertura? Esta 
unica cuestion, creo yo, es la que causa la mayoria de las variaciones en los estilos 
de codificacion (Si quiere ver una enumeracion de estilos de codificacion vea C++ 
Programming Guidelines, de [FIXME:autores] Tom Plum y Dan Saks, Plum Hall 1991), 
Intentare convencerle de que muchos de los estilos de codificacion actuales provie- 
nen de la restricciones previas al C Estandar (antes de los prototipos de funcion) de 
manera que no son apropiadas actualmente. 

Lo primero, mi respuesta a esa pregunta clave: la Have de apertura deberia ir 
siempre en la misma linea que el «precursor» (es decir «cualquier cosa de la que 
sea cuerpo: una clase, funcion, definicion de objeto, sentencia if, etc». Es una regia 
unica y consistente que aplico a todo el codigo que escribo, y hace que el formateo 
de codigo sea mucho mas sencillo. Hace mas sencilla la «escaneabilidad» - cuando 
se lee esta linea: 
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int func (int a); 


Se sabe, por el punto y coma al final de la linea, que esto es una declaration y no 
hay nada mas, pero al leer la linea: 

int func(int a) { 

inmediatamente se sabe que se trata de una definition porque la linea termina con 
una Have de apertura, y no un punto y coma. Usando este enfoque, no hay diferencia 
a la hora de colocar el parentesis de apertura en una definition de multiples lineas. 

int func (int a) { 
int b = a + 1; 
return b * 2; 

} 


y para una definition de una sola linea que a menudo se usa para inlines: 

int func (int a) { return (a + 1) * 2; } 

Igualmente, para una clase: 

class Thing; 

es una declaration del nombre de una clase, y 

class Thing { 


es una definition de clase. En todos los casos, se puede saber mirando una sola 
linea si se trata de una declaration o una definition. Y por supuesto, escribir la Have 
de apertura en la misma linea, en lugar de una linea propia, permite ahorrar espacio 
en la pagina. 

Asi que ^por que tenemos tantos otros estilos? En concreto, vera que mucha gente 
crea clases siguiente el estilo anterior (que Stroustrup usa en todas las ediciones de 
su libro The C++ Programming Language de Addison-Wesley) pero crean definiciones 
de funciones poniendo la Have de apertura en una linea aparte (lo que da lugar a 
muchos estilos de indentation diferentes). Stroustrup lo hace excepto para funciones 
inline cortas. Con el enfoque que yo describo aqui, todo es consistente - se nombra lo 
que sea (class, function, enum, etc) y en la misma linea se pone la Have de apertura 
para indicar que el cuerpo de esa cosa esta debajo. Y tambien, la Have de apertura 
se pone en el mismo sitio para funciones inline que para definiciones de funciones 
ordinarias. 

Creo que el estilo de definition de funciones que utiliza mucha gente viene de el 
antiguo prototipado de funciones de C, en el que no se declaraban los argumentos 
entre los parentesis, si no entre el parentesis de cierre y la Have de apertura (esto 
demuestra que las raices de C son el lenguaje ensamblador): 

void bar() 
int x; 
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float y; 

{ 

/* body here */ 

} 


Aqui, quedarla bastante mal poner la Have de apertura en la misma llnea, as! 
que nadie lo hacla. Sin embargo, habla distintas opiniones sobre si las llaves deblan 
indentarse con el cuerpo del codigo o deblan dejarse a nivel con el «precursor». De 
modo que tenemos muchos estilos diferentes. 

Hay otros argumentos para poner la Have en la llnea siguiente a la declaracion 
(de una clase, struct, funcion, etc). Lo siguiente proviene de un lector, y lo presento 
aqui para que sepa a que se refiere. 

Los usuarios experimentado de vi (vim) saben que pulsar la tecla «]» dos veces 
lleva el cursor a la siguiente ocurrencia de «{» (o 'L) en la columna 0. Esta caracte- 
rlstica es extremadamente util para moverse por el codigo (saltando a la siguiente 
deficion de funcion o clase). [Mi comentario: cuando yo trabajaba en Unix, GNU 
Emacs acababa de aparecer y yo me convert! en un fan suyo. Como resultado, vi 
nunca ha tenido sentido para ml, y por eso yo no pienso en terminos de «situacion 
de columna 0». Sin embargo, hay una buena cantidad de usuarios de vi ah! fuera, a 
los que les afecta esta caracteristica.] 

Poniendo la «{» en la siguiente llnea se eliminan algunas confusiones en senten- 
cias condicionales complejas, ayudando a la escaneabilidad. 

if (condl 
&& cond2 
&& cond3) { 
statement; 

} 


Lo anterior [dice el lector] tiene una escaneabilidad pobre. Sin embargo, 

if (condl 
&& cond2 
&& cond3) 

{ 

statement; 

} 

separa el i f del cuerpo, mejorando la legibilidad. [Sus opiniones sobre si eso es 
cierto variaran dependiendo para que lo haya usado.] 

Finalmente, es mucho mas facil visualizar llaves emparejadas si estan alineadas 
en la misma columna. Visualmente destacan mucho mas. [Fin del comentario del 
lector] 

El tema de donde poner la Have de apertura es probablemente el asunto en el que 
hay menos acuerdo. He aprendido a leer ambas formas, y al final cada uno utiliza 
la que le resulta mas comoda. Sin embargo, he visto que el estandar oficial de codi- 
ficacion de Java (que se puede encontar en la pagina de Java de Sun) efectivamente 
es el mismo que yo he presentado aqui - dado que mas personas estan empezando a 
programar en ambos lenguajes, la consistencia entre estilos puede ser util. 

Mi enfoque elimina todas las excepciones y casos especiales, y logicamente pro¬ 
duce un unico estilo de indentacion, Incluso con un cuerpo de funcion, la consisten- 
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cia se mantiene, como en: 


for (int i = 
cout << i 
cout << x 

} 


0; i < 100; i++) 
<< endl; 

* i << endl; 


{ 


El estilo es facil de ensenar y recordar - use una regia simple y consistente pa¬ 
ra todo sus formatos, no una para clases, dos para funciones (funciones inline de 
una linea vs. multi-lmea), y posiblemente otras para bucles, sentencias i f, etc. La 
consistencia por si sola merece ser tenida en cuenta. Sobre todo, C++ es un lenguaje 
mas nuevo que C, y aunque debemos hacer muchas concesiones a C, no deberiamos 
acarrear demasiados FIXME:artifacts que nos causen problemas en el futuro. Proble- 
mas pequenos multiplicados por muchas lineas de codigo se convierten en grandes 
problemas. Para un examen minucioso del asunto, aunque trata de C, vea C Style: 
Standards and Guidelines, de David Straker (Prentice-Hall 1992). 

La otra restriction bajo la que debo trabajar es la longitud de la linea, dado que 
el libro tiene una limitation de 50 caracteres. ^Que ocurre si algo es demasiado largo 
para caber en una linea? Bien, otra vez me esfuerzo en tener una politica consisten¬ 
te para las lineas partidas, de modo que sean facilmente visibles. Siempre que sean 
parte de una unica definicion, lista de argumentos, etc., las lineas de continuation 
deberian indentarse un nivel respecto al comienzo de la definicion, lista de argu¬ 
mentos, etc. 


A.5. Nombres para identificadores 

Aquellos que conozcan Java notaran que yo me he cambiado al estilo estandar 
de Java para todos los identificadores. Sin embargo, no puedo ser completamente 
consistente porque los identificadores en C Estandar y en librerias C++ no siguen 
ese estilo. 

El estilo es bastante sencillo. La primera letra de un identificador solo se pone en 
mayuscula si el identificador es una clase. Si es una funcion o variable, la primera 
letra siempre va en minuscula. El resto del identificador consiste en una o mas pa- 
labras, todas juntas pero se distinguen porque la primera letra de cada palabra es 
mayuscula. De modo que una clase es algo parecido a esto: 

I class FrenchVanilla : public IceCream { 


y un objeto es algo como esto: 


FrenchVanilla mylceCreamCone(3); 


y una funcion: 

void eatlceCreamCone(); 


(tanto para un metodo como para un funcion normal). 

La unica exception son las constantes en tiempo de compilation (const y# de¬ 
fine), en las que todas las letras del identificador son mayusculas. 
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El valor del estilo es que el uso de mayusculas tiene significado - viendo la pri- 
mera letra se puede saber si es una clase o un objeto/metodo. Esto es especialmente 
util cuando se invocan miembros estaticos. 


A.6. Orden de los #includes 

Los ficheros de cabecera se incluyen en orden «del mas especifico al mas gene- 
ral». Es decir, cualquier fichero de cabecera en el directorio local se incluye primero, 
despues las «herramientas» propias, como require . h, luego cabeceras de librerias 
de terceros, despues cabeceras de la libreria estandar C++, y finalmente cabeceras de 
la libreria C. 

La justificacion para esto viene de John Lakos en Large-Scale C++ Softzvare Design 
(Addison-Wesley, 1996): 

FIXME Los errores de uso latentes se puede evitar asegurando que el fi¬ 
chero .h de un componente es coherente en si mismo - sin declaraciones o 
definiciones externas. Incluir el fichero . h como primera linea del fichero 
. c asegura que no falta ninguna pieza de informacion de la interfaz fisica 
del componente en el fichero . h (o, si la hay, aparecera en cuanto intente 
compilar el fichero . c. 

Si el orden de inclusion fuese «desde el mas especifico al mas general», enton- 
ces es mas probable que si su fichero de cabecera no es coherente por si mismo, lo 
descubrira antes y prevendra disgustos en el futuro. 


A.7. Guardas de inclusion en ficheros de cabecera 

Los guardas de inclusion se usan siempre en los ficheros de cabecera para pre- 
venir inclusiones multiples durante la compilacion de un unico fichero . cpp. Los 
guardas de inclusion se implementan usado #def ine y comprobando si el nombre 
no ha sido definido previamente. El nombre que se usa para el guarda esta basa- 
do en el nombre del fichero de cabecera, pero con todas las letras en mayuscula y 
reemplazando el punto por un guion bajo. Por ejemplo: 

// IncludeGuard.h 
tifndef INCLUDEGUARD_H 
#define INCLUDEGUARD_H 
// Body of header file here... 

#endif // INCLUDEGUARD_H 

El identificador de la ultima linea se incluye unicamente por claridad. Algunos 
preprocesadores ignoran cualquier caracter que aparezca despues de un #endif, 
pero no es el comportamiento estandar y por eso el identificador aparece comentado. 


A.8. Uso de los espacios de nombres 

En los ficheros de cabecera, se debe evitar de forma escrupulosa cualquier con¬ 
tamination del espacio de nombres. Es decir, si se cambia el espacio de nombres 
fuera de una funcion o clase, provocara que el cambio ocurra tambien en cualquier 
fichero que incluya ese fichero de cabecera, lo que resulta en todo tipo de problemas. 
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No estan permitidas las declaraciones using de ningun tipo fuera de las definicio- 
nes de funcion, y tampoco deben ponerse directivas using globales en ficheros de 
cabecera. 

En ficheros cpp, cualquier directiva using global solo afectara a ese fichero, y 
por eso en este libro se usan generalmente para conseguir codigo mas legible, espe- 
cialmente en programas pequenos. 


A.9. Utilizacion de require () y assure () 

Las funciones require () y assure () definidas en requiere . h se usan cons- 
tantemente a lo largo de todo el libro, para que informen de problemas. Si se esta 
familiarizado con los conceptos de precondiciones y postcondiciones (introducidos 
por Bertrand Meyer) es facil reconocer que el uso de require () y assure () mas 
o menos proporciona precondiciones (normalmente) y postcondiciones (ocasional- 
mente). Por eso, al principio de una funcion, antes de que se ejecute el «nucleo» de 
la funcion, se comprueban las precondiciones para estar seguro de que se cumplen 
todas las condiciones necesarias. Entonces, se ejecuta el «nucleo» de la funcion, y 
a veces se comprueban algunas postcondiciones para estar seguro de que el nuevo 
estado en el que han quedado los datos esta dentro de los parametros correspon- 
dientes. Notara que las comprobaciones de postcondicion se usan raramente en este 
libro, y assure () se usa principalmente para estar seguro de que los ficheros se 
abren adecuadamente. 
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B: Directrices de Programacion 

Este apendice es una coleccion de sugerencias para programacion 
con C++. Se han reunido a lo largo de mi experiencia en como do- 
cente y programador y 

tambien de las aportaciones de amigos incluyendo a Dan Saks (co-autor junto 
a Tom Plum de C++ Programming Guidelines, Plum Hall, 1991), Scott Meyers (autor 
de Effective C++, 2 a edicion, Addison-Wesley, 1998), and Rob Murray (autor de C++ 
Strategies & Tactics, Addison-Wesley, 1993). Tambien, muchos de los consejos estan 
resumidos a partir del contenido de Thinking in C++. 

1. Primero haga que fundone, despues hagalo rapido. Esto es cierto incluso si se 
esta seguro de que una trozo de codigo es realmente importante y se sabe que 
sera un cuello de botella es el sistema. No lo haga. Primero, consiga que el sis- 
tema tenga un diseno lo mas simple posible. Entonces, si no es suficientemente 
rapido, optimicelo. Casi siempre descubrira que «su» cuello de botella no es el 
problema. Guarde su tiempo para lo verdaderamente importante. 

2. La elegancia siempre vale la pena. No es un pasatiempo frivolo. No solo per- 
mite que un programa sea mas facil de construir y depurar, tambien es mas 
facil de comprender y mantener, y ahi es donde radica su valor economico. Es¬ 
ta cuestion puede requerir de alguna experiencia para creerselo, porque puede 
parecer que mientras se esta haciendo un trozo de codigo elegante, no se es 
productivo. La productividad aparece cuando el codigo se integra sin proble- 
mas en el sistema, e incluso cuando se modifica el codigo o el sistema. 

3. Recuerde el principio «divide y venceras». Si el problema al que se enfrenta 
es desmasiado confuso, intente imaginar la operacion basica del programa se 
puede hacer, debido a la existencia de una «pieza» magica que hace el trabajo 
dificil. Esta «pieza» es un objeto - escriba el codigo que usa el objeto, despues 
implemente ese objeto encapsulando las partes dificiles en otros objetos, etc. 

4. No reescriba automaticamente todo su codigo C a C++ a menos que necesite un 
cambiar significativamente su funcionalidad (es decir, no lo arregle si no esta 
roto). Recompilar C en C++ es un positivo porque puede revelar errores ocultos. 
Sim embargo, tomar codigo C que funciona bien y reescribirlo en C++ no es la 
mejor forma de invertir el tiempo, a menos que la version C++ le ofrezca mas 
oportunidad de reutilizarlo como una clase. 

5. Si tiene un gran trozo de codigo C que necesite cambios, primero aisle las par¬ 
tes del codigo que no se modificara, posiblemente envolviendo esas funciones 
en una «clase API» como metodos estaticos. Despues ponga atencion al codigo 
que va a cambiar, recolocandolo dentro de clases para facilitar las modificacio- 
nes en el proceso de mantenimiento. 
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6. Separe al creador de la clase del usuario de la clase (el programador cliente). El 
usuario de la clase es el «consumidor» y no necesita o no quiere conocer que 
hay dentro de la clase. El creador de la clase debe ser un experto en diseno 
de clases y escribir la clase para que pueda ser usada por el programador mas 
inexperto posible, y aun asi funcionar de forma robusta en la aplicacion. El uso 
de la libreria sera sencillo solo is es transparente. 

7. Cuando cree una clase, utilice nombres tan claros como sea posible. Eo objetivo 
deberia ser que la interface del programador cliente sea conceptualmente sim¬ 
ple. Intente utilizar nombres tan claros que los comentarios sean innecesarios. 
Luego, use sobrecarga de funciones y argumentos por defecto para crear un 
interface intuitiva y facil de usar. 

8. El control de acceso permite (al creador de la clase) cambiar tanto como sea 
posible en el futuro sin afectar al codigo del cliente en el que se usa la clase. 
FIXMEds this light, mantenga todo tan privado como sea posible, y haga pu- 
blica solamente la interfaz de la clase, usando siempre metodos en lugar de 
atributos. Ponga atributos publicos solo cuando se vea obligado. Si una parte 
de su clase debe quedar expuesta a clases derivadas como protegida, propor- 
cione una interface con funciones en lugar de exponer los datos reales. De este 
modo, los cambios en la implementation tendran un impacto minimo en las 
clases derivadas. 

9. FIXME No caiga en FIXME:analysis paralysis. Hay algunas cosas que no apren- 
dera hasta que empiece a codificar y consiga algun tipo de sistema. C++ tiene 
mecanimos de seguridad de fabrica, dejelos trabajar por usted. Sus errores en 
una clase o conjunto de clases no destruira la integridad del sistema completo. 

10. El analisis y diseno debe producir, como minimo, las clases del sistema, sus 
interfaces publicas, y las relaciones con otras clases, especialmente las clases 
base. Si su metodologia de diseno produce mas que eso, preguntese a si mismo 
si todas las piezas producidas por la metodologia tiene valor respecto al tiempo 
de vide del programa. Si no lo tienen, no mantenga nada que no contribuya a 
su productividad, este es un FIXME:fact of life] que muchos metodos de diseno 
no tienen en cuenta. 

11. Escriba primero el codigo de las pruebas (antes de escribir la clase), y guar- 
delo junto a la clase. Automatice la execution de las pruebas con un makef¬ 
ile o herramienta similar. De este modo, cualquier cambio se puede verifi- 
car automaticamente ejecutando el codigo de prueba, lo que permite descubrir 
los errores inmediatamante. Como sabe que cuenta con esa red de seguridad, 
puede arriesgar haciendo cambios mas grandes cuando descubra la necesidad. 
Recuerde que las mejoras mas importantes en los lenguajes provienen de las 
pruebas que hace el compilador: chequeo de tipos, gestion de excepciones, etc., 
pero estas caracteristicas no puede ir muy lejos. Debe hacer el resto del camino 
creando un sistema robusto rellenando las pruebas que verifican las caracteris¬ 
ticas especificas de la clase o programa concreto. 

12. Escriba primero el codigo de las pruebas (antes de escribir la clase) para ve- 
rificar que el diseno de la clase esta completo. Si no puede escribir el codigo 
de pruebas, significa que no sabe que aspecto tiene la clases. En resumen, el 
echo de escribir las pruebas a menudo desvela caracteristicas adicionales o res- 
tricciones que necesita la clase - esas caracteristicas o restricciones no siempre 
aparecen durante el analisis y diseno. 
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13. Recuerde una regia fundamental de la ingenieria del software : Todos los pro- 
blemas del diseno de softzvare se pnede simplificar introduciendo una nivel mas de 
indireccion conceptual. Esta unica idea es la pase de la abstraction, la principal 
cualidad de la programacion orientada a objetos. 

14. Haga clases tan atomicas como sea posible: Es decir, de a cada clase un pro- 
posito unico y claro. Si el diseno de su clase o de su sistema crece hasta ser 
demasiado complicado, divida las clases complejas en otras mas simples. El 
indicador mas obvio es tamano total: si una clase es grande, FIXME: chances 
are it's doing demasiado y deberia dividirse. 

15. Vigile las definiciones de metodos largos. Una funcion demasiado larga y com- 
plicada es dificil y cara de mantener, y es problema que este intentado hacer 
demasiado trabajo por ella misma. Si ve una funcion asi, indica que, al menos, 
deberia dividirse en multiples funciones. Tambien puede sugerir la creation de 
una nueva clase. 

16. Vigile las listas de argumentos largas. Las llamadas a funcion se vuelven difi- 
ciles de escribir, leer y mantener. En su lugar, intente mover el metodo a una 
clase donde sea mas apropiado, y/o pasele objetos como argumentos. 

17. No se repita. Si un trozo de codigo se repite en muchos metodos de las clases 
derivadas, ponga el codigo en un metodo de la clase base e invoquelo desde 
las clases derivadas. No solo ahorrara codigo, tambien facilita la propagation 
de los cambios. Puede usar una funcion inline si necesita eficiencia. A veces 
el descubrimiento de este codigo comun anadira funcionalidad valiosa a su 
interface. 

18. Vigile las sentencias switch o cadenas de if-else. Son indicadores tipicos 
de codigo dependiente del tipo, lo que significa que esta decidiendo que codigo 
ejecutar basandose en alguna information de tipo (el tipo exacto puede no ser 
obvio en principio). Normalemente puede reemplazar este tipo de codigo por 
herencia y polimorfismo; una llamada a una funcion polimorfica efectuara la 
comprobacion de tipo por usted, y hara que el codigo sea mas fiable y sencillo 
de extender. 

19. Desde el punto de vista del diseno, busque y distinga cosas que cambian y 
cosas que no cambian. Es decir, busque elementos en un sistema que podrian 
cambiar sin forzar un rediseno, despues encapsule esos elementos en clases. 
Puede aprender mucho mas sobre este concepto en el capitulo Des sign Patterns 
del Volumen 2 de este libro, disponible en www.BruceEckel.com 1 2 

20. Tenga cuidado con las FIXME discrepancia. Dos objetos semanticamente dife- 
rentes puede tener acciones identicas, o responsabilidades, y hay una tenden- 
cia natural a intentar hacer que una sea subclase de la otra solo como beneficio 
de la herencia. Ese se llama discrepancia, pero no hay una justification real pa¬ 
ra forzar una relation superclase/subclase donde no existe. Un solution mejor 
es crear una clase base general que produce una herencia para las dos como 
clases derivadas - eso require un poco mas de espacio, pero sigue benefician- 
dose de la herencia y probablemente hara un importante descubrimiento sobre 
el diseno. 

1 Que me explico Andrew Koening. 

2 (N. de T.) Esta prevista la traduction del Volumen 2 por parte del mismo equipo que ha traducido 
este volumen. Visite FIXME 
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21. Tenga cuidado con la FIXME: limitation de la herencia. Los disenos mas limpios 
ahaden nuevas capacidades a las heredadas. Un diseno sospechoso elimina 
capacidades durante la herencia sin anadir otras nuevas. Pero las reglas estan 
hechas para romperse, y si esta trabajando con una libreria antigua, puede ser 
mas eficiente restringir una clase existente en sus subclases que restructurar 
la jerarquia de modo que la nueva clase encaje donde deberia, sobre la clase 
antigua. 

22. No extienda funcionalidad fundamental por medio de subclases. Si un elemen- 
to de la interfaz es esecial para una clase deberia estar en la clase base, no 
anadido en una clase derivada. Si esta anadiendo metodos por herencia, quiza 
deberia repensar el diseno. 

23. Menos es mas. Empiece con una interfaz minima a una clase, tan pequena y 
simple como necesite para resolver el problema que esta tratando, pero no in- 
tente anticipar todas las formas en las que se podria usar la clase. Cuando use 
la clase, descubrira formas de usarla y debera expandir la interface. Sin embar¬ 
go, una vez que que la clase este siendo usada, no podra reducir la interfaz sin 
causar problemas al codigo cliente. Si necesita anadir mas funciones, esta bien; 
eso no molesta, unicamente obliga a recompilar. Pero incluso si los nuevos me¬ 
todos reemplazan las funcionalidad de los antiguos, deje tranquila la interfaz 
existente (puede combinar la funcionalidad de la implementation subyacente 
si lo desea. Si necesita expandir la interfaz de un metodo existente anadiendo 
mas argumentos, deje los argumentos existentes en el orden actual, y ponga va- 
lores por defecto a todos los argumentos nuevos; de este modo no perturbara 
ninguna de las llamadas antiguas a esa funcion. 

24. Lea sus clases en voz alta para estar seguro que que suenan logicas, refiriendo- 
se a las relation entre una clase base y una clase derivada com «es-un» y a los 
objetos miembro como «tiene-un». 

25. Cuando tenga que decidir entre herencia y composicion, pregunte si necesi¬ 
ta hacer upcast al tipo base. Si la respuesta es no, elija composicion (objetos 
miembro) en lugar de herencia. Esto puede eliminar la necesidad de herencia 
multiple. Si hereda, los usuarios pensaran FIXME:they are supposed to upcast. 

26. A veces, se necesita heredar para acceder a miembros protegidos de una clase 
base. Esto puede conducir a una necesidad de herencia multiple. Si no necesita 
hacer upcast, primero derive una nueva clase para efectuar el acceso protegido. 
Entonces haga que la nueva clase sea un objeto miembro dentro de cualquier 
clase que necesite usarla, el lugar de heredar. 

27. Tipicamente, una clase base se usara principalmente para crear una interface 
a las clases que hereden de ella. De ese modo, cuando cree una clase base, 
haga que por defecto los metodos sean virtuales puros. El destructor puede 
ser tambien virtual puro (para forzar que los derivadas tengan que anularlo 
explicitamente), pero recuerde poner al destructor un cuerpo, porque todos 
destructores de la jerarquia se ejecutan siempre. 

28. Cuando pone un metodo virtual puro en una clase, haga que todos los me¬ 
todos de la clase sean tambien viruales, y ponga un constructor virtual. Esta 
propuesta evita sorpresas en el comportamiento de la interfaz. Empiece a qui- 
tar la palabra virtual solo cuando este intentando optimizar y su perfilador 
haya apuntado en esta direction. 
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29. Use atributos para variaciones en los valores y metodos virtuales para varia- 
ciones en el comportamiento. Es decir, si encuentra una clase que usa atribu¬ 
tos estaticos con metodos que cambian de comportamiento basandose en esos 
atributos, probablemente deberia redisenarla para expresar las diferencias de 
comportamiento con subclases y metodos virtuales anulados. 

30. If debe hacer algo no portable, cree una abstraction para el servicio y pongalo 
en una clase. Este nivel extra de indirection facilita la portabilidad mejor que 
si se distribuyera por todo el programa. 

31. Evite la herencia multiple. Estara a salvo de malas situaciones, especialmente 
cuando repare las interfaces de clases que estan fuera de su control (vea el Vo- 
lumen 2). Deberia ser un programador experimentado antes de poder disenar 
con herencia multiple. 

32. No use herencia privada. Aunque, esta en el lenguaje y parece que tiene una 
funcionalidad ocasional, ello implica ambigiiedades importantes cuando se 
combina con comprobacion dinamica de tipo. Cree un objeto miembro privado 
en lugar de usar herencia privada. 

33. Si dos clases estan asociadas entre si de algun modo (como los contenedores 
y los iteradores). intente hacer que una de ellas sea una clase amiga anidada 
de la otro, tal como la Libreria Estandar C++ hace con los interadores dentro 
de los contenedores (En la ultima parte del Capitulo 16 se muestran ejemplos 
de esto). No solo pone de manifiesto la asociacion entre las clases, tambien 
permite que el nombre de la clase se pueda reutilizar anidandola en otra clase. 
La Libreria Estandar C++ lo hace definiendo un clase iterador anidada dentro 
de cada clase contenedor, de ese modo los contenedores tienen una interface 
comun. La otra razon por la que querra anidar una clase es como parte de 
la implementation privada. En ese caso, el anidamiento es beneficioso para 
ocultar la implementation mas por la asociacion de clases y la prevention de 
la contamination del espacio de nombres citada arriba. 

34. La sobrecarga de operadores en solo «azucar sintactico:» una manera diferente 
de hacer una llamada a funcion. Is sobrecarga un operador no esta haciendo 
que la interfaz de la clase sea mas clara o facil de usar, no lo haga. Cree solo un 
operador de conversion automatica de tipo. En general, seguir las directrices y 
estilo indicados en el Capitulo 12 cuando sobrecargue operadores. 

35. No sea una victima de la optimization prematura. Ese camino lleva a la locura. 
In particular, no se preocupe de escribir (o evitar) funciones inline, hacer algu- 
nas funciones no virtuales, afinar el codigo para hacerlo mas eficiente cuando 
este en las primer fase de contraction del sistema. El objetivo principal deberia 
ser probar el diseno, a menos que el propio diseno requiera cierta eficiencia. 

36. Normalmente, no deje que el compilador cree los constructores, destructores 
o el operator= por usted. Los disehadores de clases siempre deberian decir 
que debe hacer la clase exactamente y mantenerla enteramente bajo su con¬ 
trol. Si no quiere costructor de copia u operators declarelos como privados. 
Recuerde que si crea algun constructor, el compilador un sintetizara un cons¬ 
tructor por defecto. 

37. Si su clase contiene punteros, debe crear el constructor de copia, el operator= 
y el destructor de la clase para que funcione adecuadamente. 

38. Cuando escriba un constructor de copia para una clase derivada, recuerde 11a- 
mar explicitamente al constructor de copia de la clase base (tambien cuando se 
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usan objetos miembro). (Vea el Capitulo 14.) Si no lo hace, el constructor por 
defecto sera invocado desde la case base (o el objeto miembro) y con mucha 
probabilidad no hara lo que usted espera. Para invocar el constructor de copia 
de la clase base, pasele el objeto derivado desde el que esta copiando: 

| Derived(const DerivedS d) : Base(d) { // ... 

39. Cuando escriba un operador de asignacion para una clase derivada, recuerde 
llamar explicitamente al operador de asignacion de la clase base. (Vea el Ca¬ 
pitulo 14.) SI no lo hace, no ocurrira nada (lo mismo es aplicable a los objetos 
miembro). Para invocar el operador de asignacion de la clase base, use el nom- 
bre de la clase base y el operador de resolution de ambito: 

DerivedS operator= (const DerivedS d) { 

Base::operator=(d); 

40. Si necesita minimizar las recompilaciones durante el desarrollo de un proyecto 
largo, use FIXME: demostrada en el Capitulo 5, y eliminela solo si la eficiencia 
en tiempo de ejecucion es un problema. 

41. Evite el preprocesador. Use siempre const para substitution de valores e inli¬ 
nes para las machos. 

42. Mantenga los ambitos tan pequenos como sea posible de modo que la visibili- 
dad y el tiempo de vidad de los objetos sea lo mas pequeno posible. Esto reduce 
el peligro de usar un objeto en el contexto equivocado y ello supone un bug di- 
ficil de encontrar. Por ejemplo, suponga que tiene un contenedor y un trozo de 
codigo que itera sobre el. Si copia el codigo para usarlo otro contenedor, pue- 
de que accidentalmente acabe usando el tamano del primer contenedor como 
el limite superior del nuevo. Pero, si el primer contendor estuviese fuera del 
ambito, podria detectar el error en tiempo de compilation. 

43. Evite las variables globales. Esfuercese en pones los datos dentro de clases. En 
mas probable que aparezcan funciones globales de forma natural que variables 
globales, aunque puede que despues descubra que una funcion global puede 
encajar como metodo estatico de una clase. 

44. Si necesita declara una clase o funcion de una libreria, hagalo siempre incluyen- 
do su fichero de cabecera. Por ejemplo, si quiere crear una funcion para escribir 
en un ostream, no declare nunca el ostream por usted mismo, usando una 
especificacion de tipo incompleta como esta: 

J class ostream; 

Este enfoque hace que su codigo sea vulnerabla a cambios en la representation. 
(Por ejmplo, ostream podrias ser en realidad un typedef.) En lugar de lo 
anterior, use siempre el ficheor de cabecera: 

j linclude <iostream> 

Cuando cree sus propias clases, si una libreria es grande, proporciones a sus 
usuarios una version abreviada del fichero de cabecera con especificaciones 
de tipo incompletas (es decir, declaraciones de los nombres de las clases) para 
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los casos en que ellos puedan necesitar usar unicamente punteros. (eso puede 
acelerar las compilaciones.) 

45. Cuando elija el tipo de retorno de una operador sobrecargado, considere que 
ocurrira if se encadenan expresiones. Retorne una copia o referenda al valor 
(return *this) de modo que se pueda usar e una expresion encadenada (A 
= B = C). Cuando defina el operators recuerde que x=x. 

46. Cuando escriba una funcion, pase los argumentos por referenda constante co- 
mo primera election. Siempre que no necesite modificar el objeto que esta pa- 
sando, esta es la mejor practica porque es tan simple como si lo parasa por valor 
pero sin pagar el alto precio de construir y destruir un objeto local, que es lo 
que ocurre cuando se pasa por valor. Normalmente no se querra preocupar de- 
masiado de las cuestiones de eficiencia cuando este disenando y contruyendo 
su sistema, pero este habito es una ganancia segura. 

47. Tenga cuidado con los temporaries. Cuando este optimizando, busque creacio- 
nes de temporaries, especialmente con sobrecarga de operadores. Si sus cons- 
tructores y destructores son complicados, el coste de la creacio y destruction 
de temporaries puede ser muy alto. Cuando devuelva un valor en una fun¬ 
cion, intente siempre contruir el objeto «en el sitio» (in place) con una llamada 
al constructor en la sentencia de retorno: 

j return MyType(i, j); 

mejor que 

MyType x(i, j); 
return x; 

La primera sentencia return (tambien llamada optimizacion de valor de retorno) 
evita una llamada al constructor de copia y al destructor. 

48. Cuando escriba constructores, considere las excepciones. En el mejor caso, el 
constructor no hara nada que eleve un exception. En ese escenario, la clase 
sera compuesta y heredara solo de clases robustas, de modo que ellas se lim- 
piaran automaticamente si se eleva una exception. Si requiere punteros, usted 
es responsable de capturar sus propias excepciones y de liberar los recursos an¬ 
tes de elevar una exception en su constructor. Si un contructor tiene que fallar, 
la action apropiada es elevar una exception. 

49. En los constructores, haga lo minimo necesario. No solo producira una sobre¬ 
carga menor al crear objetos (muchas de las cuales pueden quedar fuera del 
control del programador), ademas la probabilidad de que eleven excepciones 
o causen problemas sera menor. 

50. La responsabilidad del destructor es la de liberar los recursos solicitados du¬ 
rante la vida del objeto, no solo durante la construction. 

51. Utilice jerarquias de excepciones, preferiblemente derivadas de la jerarquia de 
exception estandar de C++ y anidelas como clases publicas con la clase que 
eleva la exception. La persona que captue las excepciones puede capturar los 
tipos espedficos de excepciones, seguida del tipo base. Si anade una nueva ex¬ 
ception derivada, el codigo de cliente anterior seguira capturando la exception 
por medio del tipo base. 
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52. Eleve las excepciones por valor y capturelas por referenda. Deje que el meca- 
nismo de gestion de excepciones haga la gestion de memoria. Si eleva punte- 
ros como objetos en la excepcion que han sido creados en el monticulo, el que 
capture la excepcion debe saber como liberar la excepcion, lo cual implica un 
acoplamiento perjudicial. Si captura las excepciones por valor, causara que se 
creen temporaries; peor, las partes derivadas de sus objetos-excepcion se pue- 
den partir al hacer upcasting por valor. 

53. No escriba sus propias clases plantilla a menos que debe. Mire primero en la Li- 
breria Estandar de C++, despues en librerias de proposito especifico. Adquiera 
habilidad en su uso y conseguira incrementar mucho su productividad. 

54. Cuando cree plantillas, escriba codigo que no dependa del tipo y ponga ese co- 
digo en una clase base no-plantilla para evitar que el codigo aumente de tama- 
no sin necesidad. Por medio de herencia o composicion, puede crear plantillas 
en las que el volumen de codigo que contienen es dependiente del tipo y por 
tanto esencial. 

55. No use las funciones de <stdio>, como por ejemplo printf (). Aprenda a 
usar iostreams en su lugar; son FIXME:type-safe y type-extensible, y mucho 
mas potentes. El esfuerzo se vera recompensado con regularidad. En general, 
use siempre librerias C++ antes que librerias C. 

56. Evite los tipos predefinidos de C. El soporte de C++ es por compatibilidad 
con C, pero son tipos mucho menos robustos que las clases C++, de modo que 
pueden complicar la depuracion. 

57. Siempre que use tipos predefinidos para variables globales o automaticas, no 
los defina hasta que pueda inicializarlos. Defina una variable por linea. Cuando 
defina punteros, ponga el al lado del nombre del tipo. Puede hacerlo de 
forma segura si define una variable por linea. Este estilo suele resultar menos 
confuso para el lector. 

58. Garantize que tiene lugar la inicializacion en todos los aspectos de su progra- 
ma. Inicialice todos los atributos en la lista de inicializacion del constructor, 
incluso para los tipo predefinidos (usando los pseudo-constructores). Usar la 
lista de inicializacion del constructor es normalmente mas eficiente cuando se 
inicializan subobjetos; si no se hace se invocara el constructor por defecto, y 
acabara llamando a otros metodos (probablemnte el operator=) para conse- 
guir la inicializacion que desea. 

59. No use la forma MyType a = b; para definir un objeto. Esta es una de la 
mayores fuentes de confusion porque llama a un contructor en lugar de al op- 
erator=. Por motivos de claridad, sea especifico y use mejor la forma MyType 
a (b ) ;. Los resultados son identicos, pero el lector no se podra confundir. 

60. Use los moldes explicitos descritos en el Capitulo 3. Un molde reemplaza el 
sistema normal de tipado y es un punto de error. Como los moldes explicitos 
separan los un-molde-lo hace-todo de C en clases de moldes bien-marcados, 
cualquiera que depure o mantenga el codigo podra encontrar facilmente todo 
los sitios en los que es mas probable que sucedan errores logicos. 

61. Para que un programa sea robusto, cada componente debe ser robusto. Use 
todas las herramientas que proporciona C++: control de acceso, excepciones, 
constantes, comprobacion de tipos, etc en cada clase que cree. De ese modo po¬ 
dra pasar de una forma segura al siguiente nivel de abstraccion cuando cons- 
truya su sistema. 
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62. Use las constantes con correction. Esto permite que el compilador advierta de 
errores que de otro modo serlan sutiles y dificiles de encontrar. Esta practica 
requiere de cierta disciplina y se debe usar de modo consistente en todas sus 
clases, pero merece la pena. 

63. Use la comprobacion de tipos del compilador en su beneficio. Haga todas las 
compilaciones con todos los avisos habilitados y arregle el codigo para eliminar 
todas las advertencias. Escriba codigo que utilice los errores y advertencias de 
compilacion (por ejemplo, no use listas de argumentos variables, que eliminar 
todas los comprobaciones de tipos). Use assert () para depurar, pero use 
excepciones para los errores de ejecucion. 

64. Son preferibles los errores de compilacion que los de ejecucion. Intente manejar 
un error tan cerca del punto donde ocurre como sea posible. Es mejor tratar el 
error en ese punto que elevar una excepcion. Capture cualqueir excepcion en el 
manejador mas cercano que tenga suficiente information para tratarla. Haga lo 
que pueda con la excepcion en el nivel actual; si no puede resolver el problema, 
relance la excepcion. (Vea el Volumen 2 si necesita mas detalles.) 

65. Si esta usando las especificaciones de excepcion (vea el Volumen 2 de este libro, 
disponible en www.BruceEckel.com, para aprender sobre manejo de excepcio¬ 
nes), instale su propia funcion unexpected () usando set_unexpected (). 
Su unexpected () deberia registrar el error y relanzar la excepcion actual. De 
ese modo, si una funcion existente es reemplazada y eleva excepciones, dis- 
pondra de un registro de FIXMExulprint y podra modificar el codigo que la 
invoca para manejar la excepcion. 

66. Cree un terminate () definida por el usuario (indicando un error del pro- 
gramador) para registrar el error que causo la excepcion, despues libere los 
recursos del sistema, y termine el programa. 

67. Si un destructor llama a cualquier funcion, esas funciones podrian elevar ex¬ 
cepciones. Un destructor no puede elevar una excepcion (eso podria ocasionar 
una llamada a terminate () , lo que indica un error de programacion), asi 
que cualquier destructor que llame a otras funciones debe capturar y tratar sus 
propias excepciones. 

68. No «decore» los nombres de sus atributos privados (poniendo guiones bajos, 
notation hungara, etc.), a menos que tenga un monton de valores globales ya 
existentes; en cualquier otro caso, deje que las clases y los espacios de nombres 
definan el ambito de los nombres por usted. 

69. Ponga atencion a la sobrecarga. Una funcion no deberia ejecutar codigo condi- 
cionalmente basandose en el valor de un argumento, sea por defecto o no. En 
su lugar, deberia crear dos o mas metodos sobrecargados. 

70. Oculte sus punteros dentro de clases contenedor. Dejelos fuera solo cuando 
vaya a realizar operaciones con ellos. Los punteros ha sido siempre la mayor 
fuente de errores. Cuando use new, intente colocar el puntero resultante en un 
contenedor. Es preferible que un contenedor «posea» sus punteros y sea res- 
ponsable de la limpieza. Incluso mejor, envuelva un puntero dentro de una 
clase; si aun asi quiere que parezca un puntero, sobrecargue operator-> y 
operator*. Si necesita tener un puntero normal, inicialicelo siempre, preferi- 
blemente con la direction de un objeto, o cero si es necesario. Asignele un cero 
cuando le libere para evitar liberaciones multiples. 
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71. No sobrecargue los new y delete globales. Hagalo siempre en cada clase. 
Sobrecargar las versiones globales affecta la proyecto completo, algo que solo 
los creadores del proyecto deberia controlar. Cuando sobrecargue new y de¬ 
lete en las clases, no asume que conoce el tamano del objeto; alguien puede 
heredar de esa clase. Use el argumento proporcionado. Si hace algo especial, 
considere el efecto que podria tener en las clases derivadas. 

72. Evite el troceado de objetos. Practicamente nunca tiene sentido hacer upcast 
de un objeto por valor. Para evitar el upcast por valor, use metodos virtuales 
puros en su clase base. 

73. A veces la agregacion simple resuelve el problema. Un FIXME:«sistema confor- 
me al pasajero» en una linea aerea consta en elementos desconectados: asien- 
to, aire acondicionado, video, etc., y todavia necesita crear muchos mas en un 
avion. ^Debe crear miembros privados y construir una nueva interfaz comple- 
ta? No - en este caso, los componentes tambien son parte de la interfaz publica, 
asi que deberian ser objetos miembros publicos. Esos objetos tienen sus propias 
implementaciones privadas, que contimian seguras. Sea consciente de que la 
agregacion simple no es una solucion usan a menudo, pero que puede ocurrir. 
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C: Lecturas recomendadas 

C.l. Sobre C 

Thinking in C: Foundations for Java & C++, por Chuck Allison (un seminario en 
CDROM de Mind View, Inc., 2000, incluido al final de este libro y disponible tambien 
en www.BruceEckel.com). Se trata de un curso que incluye lecciones y transparen- 
cias sobre los conceptos basicos del lenguaje C para preparar al lector a aprender Java 
o C++. No es un curso exhaustivo sobre C; solo contiene lo necesario para cambiar- 
se a esos otros lenguajes. Unas secciones adicionales sobre esos lenguajes concretos 
introducen al aspirante a programador en C++ o en Java, a sus caracterlsticas. Requi¬ 
sites previos: alguna experiencia con un lenguaje de alto nivel, como Pascal, BASIC, 
Fortran, o LISP (serla posible avanzar por el CD sin ese bagaje, pero el curso no esta 
pensado para servir de introduccion basica a la programacion). 


C.2. Sobre C++ en general 

The C++ Programming Language, 3 a edition, por Bjarne Stroustrup (Addison-Wesley 
1997).Hasta cierto punto, el objetivo de la obra que tiene en sus manos es permitirle 
usarel libro de Bjarne a modo de referenda. Dado que contiene la descripcion del 
lenguaje por su propio autor, es tlpicamente ahr donde se mira para resolver dudas 
sobre que se supone que C++ debe o no debe hacer. Cuando empiece a dominar el 
lenguaje y este preparado para pasar a las cosas serias, lo necesitara. 

C++ Primer, 3 a Edition, por Stanley Lippman y Josee Lajoie (Addison-Wesley 1998). 
Ha dejado de ser una introduccion; se ha convertido en un voluminoso libro muy 
detallista, y es uno de los que consulto junto con el de Stroustrup cuando intento 
resolver una cuestion.«Pensar En C++» debe proporcionar una base para entender 
C++ Primer as! como el libro de Stroustrup. 

C & C++ Code Capsides, por Chuck Allison (Prentice-Hall, 1998).Ese libro presu- 
pone unconocimiento de C y C++, y trata cuestiones que ya hayan sido quebraderos 
decabeza, o que no logro zanjar adecuadamente a la primera. La obra soluciona la¬ 
gunas tanto en C como en C++. 

The C++ Standard. Ese es el documento en el que el comite ha trabajado tanto 
durante anos. No es gratis, desgraciadamente. Pero por lo menos se puede adquirir 
en formato PDF por solo $18 en www.cssinfo.com. 


C.2.1. Mi propia lista de libros 

Aparecen a continuacion ordenados por fecha de publication. No todos estan a 
la venta actualmente. 


541 


©- 


0 


0 


0 











'Volumenl" — 2012/1/12 — 13:52 — page 542 — #580 


Apendice C. Lecturas recomendadas 


Computer Interfacing with Pascal & C(publicado por mi, via Eisys, en 1988. Dispo- 
nible unicamente a traves de www.BruceEckel.com). Es una introduccion a la elec- 
tronica desde los dias en los que CP/M era aun el rey y MSDoS solo un principiante. 
Utilice lenguajes de alto nivel y a menudo el puerto paralelo del ordenador para pi- 
lotar varios proyectos electronicos. Se trata de una adaptacion de mis columnas en la 
primera y mejor revista para la que trabaje, Micro Cornucopia (retomando las palabras 
de Larry o_Brien, editor durante muchos anos de Softivare Development Magazine: la 
mejor revista de electronica jamas publicada -jhasta daban los pianos para fabricar 
un robot a partir de una maceta!). Desgraciadamente, MicroC dejo de existir mucho 
antes de que apareciese el Internet. Crear ese libro fue una experiencia editorial muy 
gratificante para mi. 

Using C++ (osborne/McGraw-Hill 1989). Fue uno de los primeros libros publi- 
cados acerca de C++. Esta agotado y ha sido reemplazado por su segunda edicion, 
bajo el nuevo titulo «C++ Inside & out.» 

C++ Inside & out (osborne/McGraw-Hill 1993).Como se indico antes, es en reali¬ 
dad la segunda edicion de «Using C++». El lenguaje C++ que describe el libro es bas- 
tante correcto, pero data de 1992 y «Pensar En C++» esta llamado a sustituirlo. Puede 
saber mas acerca de ese libro y conseguir el codigo fuente en www.BruceEckel.com. 

Thinking in C++, 1“ edition (Prentice-Hall 1995). 

Black Belt C++, the Master's Collection, Bruce Eckel, editor (M&T Books 1994).Ago¬ 
tado. Esta constituido por una serie de capitulos escritos por personas de prestigio 
sobre la base de sus presentaciones en el coloquio sobre C++ durante la Conferencia 
sobre Desarrollo de Software que yo presidi. La portada del libro me llevo a ejercer 
desde entonces mas control sobre el diseno de las portadas. 

Thinking in Java, 2 a edicion (Prentice-Hall, 2000). La primera edicion de ese li¬ 
bro gano el Premio a la Productividad del Software Development Magazine y tam¬ 
bien el Premio del Editor 1999 del Java Developer_s Journal. Se puede descargar desde 
www.BruceEckel.com. 


C.3. Los rincones oscuros 

Estos libros profundizan en aspectos del lenguaje, y ayudan a evitar los tipicos 
errores inherentes al desarrollo de programas en C++. 

Effective C++(2 a Edicion, Addison-Wesley 1998) y «More Effective C++» (Addison- 
Wesley 1996), por Scott Meyers. La obra clasica e indispensable para resolver los 
problemas serios y disenar mejor codigo en C++. He intentado capturar y plasmar 
muchos de los conceptos de esos libros en Pensar en C++, pero no pretendo haberlo 
logrado. Cualquiera que dedica tiempo a C++ acaba teniendo esos libros. Tambien 
disponible en CDRoM. 

Ruminations on C++, por Andrew Koenig y Barbara Moo (Addison-Wesley, 1996).An- 
drew trabajo personalmente con Stroustrup en muchos aspectos del lenguaje C++ y 
es por tanto una voz muy autorizada. Me encantaron sus incisivos comentarios y he 
aprendido mucho con el, tanto por escrito como en persona, a lo largo de los anos. 

Large-Scale C++ Softivare Design , por John Lakos(Addison-Wesley, 1996).Trata te- 
mas y contesta a preguntas con las que uno se encuentra durante la creacion de 
grandes proyectos, y a menudo de pequenos tambien. 

C++ Gems editor (SIGS Publications, 1996). Una seleccion de articulos extraidos 
de The C++ Report. 
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The Design & Evolution of C++ , por Bjarne Stroustrup (Addison-Wesley 1994). Acla- 
raciones del inventor de C++ acerca de por que tomo ciertas decisiones durante su 
diseno. No es esencial, pero resulta interesante. 


C.4. Sobre Analisis y Diseno 

Extreme Programming Explained por Kent Beck (Addison-Wesley 2000).;Adoro ese 
libro! Si,se que tengo tendencia a tomar posturas radicales, pero siempre habia intui- 
do que podia haber un proceso de desarrollo de programas muy diferente, y mucho 
mejor, y pienso que XP se acerca bastante a ello. El unico libro que me impacto de 
forma similar, fue PeopleWare (descrito a continuacion), que trata de los entornos y la 
interaccion con la cultura de las empresas. Extreme Programming Explained habia de 
programacion, y echa abajo la mayoria de las cosas, incluso los recientes «hallazgos». 
Llega al punto de decir que los dibujos estan bien mientras que no se les dedique de- 
masiado tiempo y se este dispuesto a tirarlos a la basura. (observen que ese libro 
no lleva el «sello de certification UML» en su porta da). Comprenderia que alguien 
decidiese si quiere trabajar o no para una compania, basandose solo en el hecho que 
usan XP. Es un libro pequeno, con capitulos cortos, facil de leer, y que da mucho que 
pensar. Uno empieza a imaginarse trabajando en esa atmosfera y vienen a la mente 
visiones de un mundo nuevo. 

UML Distilled por Martin Fowler (2 a edition, Addison-Wesley, 2000).Cuando se 
descubre UML por primera vez, resulta intimidante porque hay tantos diagramas 
y detalles. Segun Fowler, la mayoria de esa parafernalia es innecesaria, asi que se 
queda solo con lo esencial. Para la mayoria de los proyectos, solo se necesitan unos 
pocos instrumentos graficos, y el objetivo de Fowler es llegar a un buen diseno en 
lugar de preocuparse por todos los artefactos que permiten alcanzarlo. Es un libro 
corto, muy legible; el primer libro que deberia conseguir si necesita entender UML. 

The Unified Softzvare Development Process por Ivar Jacobsen, Grady Booch, y James 
Rumbaugh (Addison-Wesley 1999). Estaba mentalizado para que no me gustase ese 
libro. Parecia tener todos los ingredientes de un aburrido texto universitario. Me 
quede gratamente sorprendido - solo unos islotes dentro del libro contienen explica- 
ciones que dan la impresion que los conceptos no han quedado claros para los pro- 
pios autores. La mayoria del libro es no solamente claro, sino agradable. Y lo mejor 
de todo, es que el proceso tiene realmente sentido. Esto no es Extreme Programming 
(y no tiene su claridad acerca de los tests) pero tambien forma parte del mastodonte 
UML - incluso si usted no consigue hacer adoptar XP, la mayoria de la gente se ha 
subido al carro de "UML es bueno” (independientemente de su nivel de experiencia 
real con el) asi que podria conseguir que lo adopten. Pienso que ese libro deberia ser 
el buque insignia del UML, y es el que se debe de leer despues del UML Distilled de 
Fowler en cuanto se desee tener mas nivel de detalle. 

Antes de elegir metodo alguno, es util enriquecer su perspectiva traves de los 
que no estan intentando vender ninguno. Es facil adoptar un metodo sin entender 
realmente lo que se desea conseguir con el o lo que puede hacer por uno. otras per¬ 
sonas lo estan usando, lo cual parece una buena razon. Sin embargo, los humanos 
tienen un extrano perfil psicologico: si quieren creer que algo va a solucionar sus 
problemas, lo van a probar. (Eso se llama experimentation, que es una cosa buena) 
Pero si eso no les resuelve nada, redoblaran sus esfuerzos y empezaran a anunciar 
por todo lo alto su fabuloso descubrimiento. (Eso es negation de la realidad, que no 
es bueno) La idea parece consistir en que si usted consigue meter a mas gente en 
el mismo barco, no se sentira solo, incluso si no va a ninguna parte (o se hunde). 
No estoy insinuando que todas las metodologias no llevan a ningun lado, pero hay 
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que estar armado hasta los dientes con herramientas mentales que ayuden a seguir 
en el modo de experimentacion («Esto no funciona, vamos a probar otra cosa») y 
no en el de negacion («No, no es problema. Todo va maravillosamente, no necesita- 
mos cambiar»). Creo que los libros siguientes, leidos antes de elegir un metodo, le 
proporcionaran esas herramientas. 

Softzvare Creativity, por Robert Glass (Prentice-Hall, 1995).Ese es el mejor libro que 
he leldo que describa una vision de conjunto sobre el debate de las metodologias. 
Consta de una serie de ensayos cortos y articulos que Glass ha escrito o comprado 
(P.J. Plauger es uno de los que contribuyen al libro), que reflejan sus numerosos anos 
dedicados a pensar y estudiar el tema. Son amenos y de la longitud justa para decir 
lo necesario; no divaga ni aburre al lector. Pero tampoco vende simplemente aire; 
hay centenares de referencias a otros articulos y estudios. Todos los programado- 
res y jefes de proyecto deberian leer ese libro antes de caer en el espejismo de las 
metodologias. 

Softzvare Runazvays: Monumental Softzvare Disasters, por Robert Glass (Prentice- 
Hall 1997).Lo realmente bueno de ese libro es que expone a la luz lo que nunca 
contamos: la cantidad de proyectos que no solo fracasan, sino que lo hacen espec- 
tacularmente. Veo que la mayoria de nosotros aun piensa «Eso no me va a pasar a 
mi» (o «Eso no volvera a pasarme») y creo que eso nos desfavorece. Al tener siempre 
en mente que las cosas pueden salir mal, se esta en mejor posicion para hacerlas ir 
bien. 

Object Lessons por Tom Love (SIGS Books, 1993). otro buen libro para tener «pers- 
pectiva». 

Peoplezvare , por Tom Demarco y Timothy Lister (Dorset House, 2 a edicion 1999).A 
pesar de que tiene elementos de desarrollo de software, ese libro trata de proyectos 
y equipos de trabajo en general. Pero el entasis esta puesto en las personas y sus 
necesidades, y no en las tecnologias. Se habla de crear un entorno en el que la gente 
este feliz y productiva, en lugar de decidir las reglas que deben seguir para conver- 
tirse perfectos engranajes de una maquina. Esta ultima actitud, pienso yo, es lo que 
mas contribuye a que los programadores sonrian y digan si con la cabeza cuando un 
metodo es adoptado y sigan tranquilamente haciendo lo mismo que siempre. 

Complexity, by M. Mitchell Waldrop (Simon & Schuster, 1992). Relata el encuen- 
tro entre un grupo de cientificos de diferentes disciplinas en Santa Fe, Nuevo Meji- 
co, para discutir sobre problemas reales que como especialistas no podian resolver 
aisladamente (el mercado bursatil en economia, la formacion inicial de la vida en 
biologia, por que la gente se comporta de cierta manera en sociologia, etc.). Al re- 
unir la fisica, la economia, la quimica, las matematicas, la informatica, la sociologia, 
y otras ciencias, se esta desarrollando un enfoque multidisciplinar a esos problemas. 
Pero mas importante aun, una nueva forma de pensar en esos problemas extrema- 
damente complejos esta apareciendo: alejandose del determinismo matematico y de 
la ilusion de poder escribir una formula que prediga todos los comportamientos, 
hacia la necesidad de observar primero y buscar un patron para despues intentar 
emularlo por todos los medios posibles. (El libro cuenta, por ejemplo, la aparicion 
de los algoritmos geneticos). Ese tipo de pensamiento, creo yo, es util a medida que 
investigamos formas de gestionar proyectos de software cada vez mas complejos. 



